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

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

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

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

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

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

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

    תרשים של אתר של חנות גבינות עם לחצן של BobPay (אפליקציית תשלומים).

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

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

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

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

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

    תרשים שבו מוצג הלקוח לוחץ על

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

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

  • אמצעי תשלום קבילים והנתונים שלהם לצורך עיבוד העסקה.
  • פרטים, כמו המחיר הכולל (חובה) ומידע על הפריטים.
  • אפשרויות שבהן מוכרים יכולים לבקש פרטי משלוח, כמו כתובת למשלוח ואפשרות משלוח.
  • המוכרים יכולים גם לבקש את הכתובת לחיוב, את שם המשלם, כתובת האימייל ומספר הטלפון.
  • המוכרים יכולים לציין גם סוג משלוח (shipping, delivery או pickup) ב-PaymentRequest. אפליקציית התשלומים יכולה להשתמש בזה כהנחיה כדי להציג את התוויות הנכונות בממשק המשתמש שלה.
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'
});
כולל מזהה עסקה

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

המוכר יכול להעביר מזהה עסקה כחלק מהמאפיין 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: הלקוח לוחץ על לחצן התשלום

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

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

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

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

כדי לדחות את הצגת ממשק המשתמש של התשלום, המוכר מעביר הבטחה (promise) לשיטה 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(), הדפדפן יפעיל את ממשק המשתמש של התשלום באופן מיידי.

שלב 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
  });
});

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

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

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

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

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

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

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

השלמת העסקה או ניסיון חוזר לבצע אותה

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

  • כדי להשלים את העסקה ולהסתיר את אינדיקטור הטעינה, צריך לבצע קריאה ל-method‏ .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();

השלבים הבאים