דף זה תורגם על ידי Cloud Translation API.

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

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

Eiji Kitamura

Milica Mihajlija

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

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

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

התהליך כולל 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, שמפעילה באופן מיידי את ממשק המשתמש של התשלום.

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

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

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

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

השלבים הבאים

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