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

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

Eiji Kitamura

Milica Mihajlija

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

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

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

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

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

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

   

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

   

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

   

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

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

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

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

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

כדי ללמוד בפירוט על תהליך הגילוי, עיינו במאמר הגדרת תשלום .

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

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

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

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

כדי לדחות את ממשק המשתמש של התשלום, המוכר מעביר הבטחה לאמצעי התשלום 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.
• אפשר ללמוד איך לבנות אפליקציית תשלומים מבוססת-אינטרנט, בפלטפורמה למפתחים של אפליקציות תשלומים מבוססות-אינטרנט guide.