מחזור החיים של עסקת תשלום

איך מוכרים משלבים אפליקציות תשלומים ואיך עסקאות תשלום פועלות עם Payment Request API.

אייג'י קיטמורה

מיליקה מיהאג'ליג'ה

ממשקי Web Payments API הם תכונות תשלום ייעודיות שמובנות בדפדפן בפעם הראשונה. באמצעות Web Payments, שילוב המוכרים עם אפליקציות תשלומים נעשה פשוט יותר, וחוויית הלקוח הרבה יותר פשוטה ומאובטחת.

למידע נוסף על יתרונות השימוש בשירות תשלומים באינטרנט, קראו את המאמר שימוש ב-Web Payments לקבלת מידע נוסף.

במאמר הזה נסביר איך לבצע טרנזקציות באתר של המוכר ואיך פועל השילוב עם אפליקציית תשלומים.

התהליך כולל 6 שלבים:

1. המוכר מבצע עסקת תשלום.
2. המוכר מציג לחצן תשלום.

3. הלקוח לוחץ על לחצן התשלום.

   

4. הדפדפן מפעיל את אפליקציית התשלומים.

   

5. אם הלקוח ישנה פרטים כלשהם (כמו אפשרויות המשלוח או הכתובת שלו), המוכר יעדכן את פרטי העסקה שמשקפים את השינוי.

   

6. אחרי שהלקוח מאשר את הרכישה, המוכר מאמת את התשלום ומשלים את העסקה.

   

שלב 1: המוכר מבצע עסקת תשלום

כשלקוח מחליט לבצע רכישה, המוכר יוצר אובייקט PaymentRequest כדי ליזום את עסקת התשלום. האובייקט הזה כולל מידע חשוב על העסקה:

• אמצעי תשלום קבילים והנתונים שלהם לעיבוד העסקה.
• פרטים, כמו המחיר הכולל (חובה) ומידע על הפריטים.
• אפשרויות שבהן המוכרים יכולים לבקש פרטי משלוח, כמו כתובת למשלוח ואפשרות משלוח.
• מוכרים יכולים גם לבקש את הכתובת לחיוב, שם המשלם, כתובת האימייל ומספר הטלפון.
• המוכרים יכולים לכלול במאפיין PaymentRequest גם סוג משלוח (shipping, delivery או pickup). אפליקציית התשלומים יכולה להשתמש במידע הזה כרמז להצגת התוויות הנכונות בממשק המשתמש שלה.

const request = new PaymentRequest([{
  supportedMethods: 'https://bobpay.xyz/pay',
  data: {
    transactionId: '****'
  }
}], {
  displayItems: [{
    label: 'Anvil L/S Crew Neck - Grey M x1',
    amount: { currency: 'USD', value: '22.15' }
  }],
  total: {
    label: 'Total due',
    amount: { currency: 'USD', value : '22.15' }
  }
}, {
  requestShipping: true,
  requestBillingAddress: true,
  requestPayerEmail: true,
  requestPayerPhone: true,
  requestPayerName: true,
  shippingType: 'delivery'
});

כולל מזהה עסקה

סוגים מסוימים של רכיבי handler של תשלומים עשויים לדרוש מהמוכר לספק את מזהה העסקה שהוא הנפיק מראש, כחלק מפרטי העסקה. שילוב אופייני כולל תקשורת בין השרת של המוכר לשרת של handler של התשלומים כדי לשמור את המחיר הכולל. פעולה זו מונעת מלקוחות זדוניים לשנות את המחיר ולהונות את המוכר באמצעות אימות בסוף העסקה.

המוכר יכול להעביר מזהה עסקה כחלק מהמאפיין data של האובייקט PaymentMethodData.

אם מספקים את פרטי העסקאות, הדפדפן עובר תהליך גילוי של אפליקציות תשלום שצוינו ב-PaymentRequest על סמך המזהים של אמצעי התשלום. כך הדפדפן יכול לקבוע איזו אפליקציית תשלום תופעל ברגע שהמוכר מוכן להמשיך בעסקה.

למידע מפורט על תהליך הגילוי, אפשר לקרוא את המאמר הגדרת אמצעי תשלום.

שלב 2: המוכר מציג לחצן תשלום

המוכרים יכולים לתמוך באמצעי תשלום רבים, אבל עליהם להציג את לחצני התשלום רק עבור אלה שהלקוחות יכולים להשתמש בהם בפועל. הצגה של לחצן תשלום שלא ניתן לשימוש גורמת לחוויית משתמש גרועה. אם המוכר יכול לחזות שאמצעי תשלום שצוין באובייקט PaymentRequest לא יפעל ללקוח, הוא יכול לספק פתרון חלופי או לא להציג את הלחצן הזה בכלל.

באמצעות מופע של PaymentRequest, מוכר יכול לבדוק אם אפליקציית התשלום זמינה ללקוח.

האם אפליקציית התשלום זמינה ללקוח?

השיטה canMakePayment() של PaymentRequest מחזירה true אם אפליקציית תשלום זמינה במכשיר של הלקוח. המשמעות של הסטטוס 'זמינה' היא שהתגלתה אפליקציית תשלומים שתומכת באמצעי התשלום, שאפליקציית התשלומים הספציפית לפלטפורמה מותקנת בו או שאפליקציית התשלומים מבוססת-האינטרנט מוכנה לרישום.

const canMakePayment = await request.canMakePayment();
if (!canMakePayment) {
  // Fallback to other means of payment or hide the button.
}

שלב 3: הלקוח לוחץ על לחצן התשלום

כשהלקוח לוחץ על לחצן התשלום, המוכר מבצע קריאה ל-method show() של המכונה של PaymentRequest, שמפעילה מיד את ממשק המשתמש של התשלומים.

במקרה שהמחיר הכולל הסופי מוגדר באופן דינמי (לדוגמה, מאוחזר משרת), המוכר יכול לדחות את ההשקה של ממשק המשתמש של התשלומים עד לסכום הכולל.

דחיית ההשקה של ממשק המשתמש לתשלומים

מומלץ לצפות בהדגמה של דחיית ממשק המשתמש של התשלומים עד לקביעה של המחיר הכולל הסופי.

כדי לדחות את ממשק המשתמש של התשלומים, המוכר מעביר הבטחה ל-show(). אינדיקטור הטעינה יוצג בדפדפן עד שההבטחה תיסגר והעסקה תהיה מוכנה.

const getTotalAmount = async () => {
  // Fetch the total amount from the server, etc.
};

try {
  const result = await request.show(getTotalAmount());
  // Process the result…
} catch(e) {
  handleError(e);
}

אם לא צוין הבטחה כארגומנט עבור show(), הדפדפן יפעיל את ממשק המשתמש של התשלומים באופן מיידי.

הערה: אם ה-handler של התשלומים מיועד להחזיר מזהה עסקה לאחר הגדרת המחיר הכולל, אפשר להעביר את המזהה כחלק מהתוצאה שהובטחה.

שלב 4: הדפדפן מפעיל את אפליקציית התשלום

הדפדפן יכול להפעיל אפליקציית תשלומים ספציפית לפלטפורמה או אפליקציית תשלומים מבוססת אינטרנט (למידע נוסף על האופן שבו Chrome קובע איזו אפליקציית תשלומים תופעל).

המבנה של אפליקציית התשלומים נקבע ברובו על ידי המפתח, אבל האירועים שמיוצאים מהמוכר ואליו, ומבנה הנתונים שמועברים עם האירועים האלה, מותאמים לסטנדרטים סטנדרטיים.

כשאפליקציית התשלומים מופעלת, היא מקבלת את פרטי העסקה שמועברים לאובייקט PaymentRequest בשלב 1, כולל:

• נתוני אמצעי התשלום
• מחיר כולל
• אפשרויות התשלום

אפליקציית התשלומים משתמשת בפרטי העסקה כדי להוסיף תוויות לממשק המשתמש שלה.

שלב 5: איך מוכרים יכולים לעדכן את פרטי העסקה בהתאם לפעולות של הלקוח

הלקוחות יכולים לשנות את פרטי העסקה, כמו אמצעי התשלום ואפשרות המשלוח באפליקציית התשלום. בזמן שהלקוח מבצע שינויים, המוכר מקבל את אירועי השינוי ומעדכן את פרטי העסקה.

מוכר יכול לקבל ארבעה סוגים של אירועים:

• אירוע שינוי אמצעי תשלום
• אירוע של שינוי הכתובת למשלוח
• אירוע של שינוי אפשרות משלוח
• אירוע אימות של מוכר

אירוע שינוי אמצעי תשלום

אפליקציית תשלומים יכולה לתמוך בכמה אמצעי תשלום, ומוכר עשוי להציע הנחה מיוחדת בהתאם לבחירת הלקוח. כדי לתת מענה לתרחיש לדוגמה הזה, אירוע השינוי של אמצעי התשלום יכול ליידע את המוכר לגבי אמצעי התשלום החדש, כדי שהוא יוכל לעדכן את המחיר הכולל עם ההנחה ולהחזיר אותו לאפליקציית התשלום.

request.addEventListener('paymentmethodchange', e => {
  e.updateWith({
    // Add discount etc.
  });
});

אירוע של שינוי הכתובת למשלוח

אפליקציית תשלומים יכולה לספק את הכתובת למשלוח של הלקוח. זה נוח ללקוחות כי הם לא צריכים להזין פרטים באופן ידני בטופס, והם יכולים לשמור את הכתובת למשלוח באפליקציות התשלום המועדפות עליהם, במקום בכמה אתרים שונים של מוכרים.

אם לקוח יעדכן את הכתובת למשלוח באפליקציית תשלום אחרי ביצוע העסקה, למוכר יישלח למוכר האירוע 'shippingaddresschange'. האירוע הזה עוזר למוכר לקבוע את עלות המשלוח על סמך הכתובת החדשה, לעדכן את המחיר הכולל ולהחזיר אותו לאפליקציית התשלומים.

request.addEventListener('shippingaddresschange', e => {
  e.updateWith({
    // Update the details
  });
});

אם המוכר לא יכול לבצע משלוחים לכתובת המעודכנת, הוא יכול להציג הודעת שגיאה על ידי הוספת פרמטר שגיאה לפרטי הטרנזקציה שמוחזרים באפליקציית התשלומים.

הערה: המוכרים לא מקבלים את הכתובת המלאה למשלוח של הלקוחות עד שהם מאשרים את התשלום.

אירוע של שינוי אפשרות משלוח

המוכר יכול להציע ללקוח כמה אפשרויות משלוח, ולהאציל את ההרשאות שלו לאפליקציית התשלום. אפשרויות המשלוח מוצגות כרשימה של מחירים ושמות שירותים שהלקוח יכול לבחור מתוכם. לדוגמה:

• משלוח רגיל – חינם
• משלוח מהיר – 20 ש"ח

כשלקוח יעדכן את אפשרות המשלוח באפליקציית תשלום, יישלח למוכר אירוע 'shippingoptionchange'. המוכר יכול לקבוע את עלות המשלוח, לעדכן את המחיר הכולל ולהחזיר אותו לאפליקציית התשלומים.

request.addEventListener('shippingoptionchange', e => {
  e.updateWith({
    // Update the details
  });
});

המוכר יכול לשנות באופן דינמי את אפשרויות המשלוח בהתאם לכתובת למשלוח של הלקוח. האפשרות הזו שימושית כשמוכר רוצה להציע קבוצות שונות של אפשרויות משלוח ללקוחות מקומיים ובינלאומיים.

אירוע אימות של מוכר

כאמצעי אבטחה נוסף, אפליקציית תשלומים יכולה לבצע אימות מוכר לפני שממשיכים בתהליך התשלום. העיצוב של מנגנון האימות תלוי באפליקציית התשלום, אבל אירוע האימות של המוכר נועד ליידע את המוכר לגבי כתובת ה-URL שהוא יכול להשתמש בו כדי לאמת את זהותו.

request.addEventListener('merchantvalidation', e => {
  e.updateWith({
    // Use `e.validateURL` to validate
  });
});

הערה: התמיכה באירוע האימות של המוכר מוגבלת ל-Apple Safari. נכון למאי 2020, האירוע הזה לא הוטמע בדפדפנים שמבוססים על Chromium.

שלב 6: המוכר מאמת את התשלום ומשלים את העסקה

כשהלקוח מאשר את התשלום, השיטה show() מחזירה הבטחה שמובילה ל-PaymentResponse. האובייקט PaymentResponse כולל את המידע הבא:

• פרטים של תוצאת תשלום
• כתובת למשלוח
• אפשרות משלוח
• פרטים ליצירת קשר

בשלב הזה, יכול להיות שבממשק המשתמש של הדפדפן עדיין יופיע אינדיקטור של טעינה שמסמן שהעסקה עוד לא הושלמה.

אם אפליקציית התשלומים נסגרת בגלל כשל בתשלום או שגיאה, ההבטחה שהוחזרה מ-show() תידחה והדפדפן יסיים את עסקת התשלום.

עיבוד ואימות התשלום

details ב-PaymentResponse הוא האובייקט של פרטי הכניסה לתשלום שהוחזר מאפליקציית התשלום. המוכר יכול להשתמש בפרטי הכניסה כדי לעבד את התשלום או לאמת אותו. אופן הפעולה הקריטי של התהליך תלוי בגורם המטפל בתשלומים.

השלמת העסקה או ניסיון נוסף לבצע אותה

אחרי שהמוכר קובע אם העסקה הצליחה או נכשלה, הוא יכול:

• מפעילים את השיטה .complete() כדי להשלים את הטרנזקציה ולסגור את אינדיקטור הטעינה.
• אפשר ללקוח לנסות שוב על ידי קריאה לשיטה retry().

async function doPaymentRequest() {
  try {
    const request = new PaymentRequest(methodData, details, options);
    const response = await request.show();
    await validateResponse(response);
  } catch (err) {
    // AbortError, SecurityError
    console.error(err);
  }
}

async function validateResponse(response) {
  try {
    const errors = await checkAllValuesAreGood(response);
    if (errors.length) {
      await response.retry(errors);
      return validateResponse(response);
    }
    await response.complete("success");
  } catch (err) {
    // Something went wrong…
    await response.complete("fail");
  }
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();

השלבים הבאים

• במאמר הגדרת אמצעי תשלום מוסבר איך מצהירים בפירוט על מזהה אמצעי התשלום.
• במדריך למפתחים בנושא אפליקציות תשלומים ל-Android מוסבר איך ליצור אפליקציית תשלום ספציפית לפלטפורמה.
• במדריך למפתחים בנושא אפליקציות לתשלומים מבוססי-אינטרנט מוסבר איך יוצרים אפליקציית תשלום מבוססת אינטרנט.