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

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

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

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

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

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

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

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

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

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

  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
  });
});

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

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

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

  • משלוח רגיל – חינם
  • משלוח מהיר – 5$

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

השלבים הבאים