איך תשלומי API עובדים לספקים

התשלום API הוא חוזה בין הבקשה שלך לבין הספק שהופך את ”ליצור תשלום”, ”לאשר” 3DS, ”החזר”, ”לשלם ללקוח” ו ”לקבל מעמד” לשיחות אמינות וניתנות לחזרה. מתחת למכסה המנוע יש עשרות חוקים: אסימונים, אידמפוטנציה, פנקסי אינטרנט, אנטי הונאה, תורים, SLA וביקורת. להלן מפה מעשית של איך זה עובד עבור רוב הספקים.

מודל בסיסי: אילו ישויות הן כמעט תמיד

תשלום/טעינה - ניסיון לרשום (לאשר + לכידה או רכישה מיידית).

שיטת תשלום - כרטיס (PAN/token), חשבון בנק/כינוי, ארנק, שיטה מקומית.

ישות לקוח/משלם (לפעמים אופציונלי).

תשלום/העברה - תשלום יוצא ללקוח/סוחר.

החזר/היפוך - החזר לתשלום המקורי (לולאה סגורה).

אירוע Webhook - הודעת מצב אסינכרוני.

מחלוקת/Chargback - מחלוקת על רשת התשלומים (עבור כרטיסים).

הזמנה/חשבונית - הקשר עסקי סביב התשלום.

אימות וביטחון

מפתחות API/OAuth 2. 0/mTLS לשרת לשרת.

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

אסימון קלפים - PAN הולך לספק; אתה מאחסן רק את האסימון.

PCI DSS - אם אתה רואה PAN, אתה באזור PCI; עדיף להימנע ולהשתמש בשדות מארחים/SDKs.

חתימת HMAC מקוונת בודקת שהאירוע הגיע מהספק.

ארכיטקטורה דו-אזורית - חזית ציבורית (JS/SDK) וגב פרטי (מפתחות, היגיון סיכון).

אידמפוטנטיות, תורים ועקביות

Idempotency-Key בכותרת: חזרה על הבקשה (עם פסק זמן) לא יוצרת העתק.

Outbox/Saga איתך: ”לשלוח תשלום _ לכתוב לפנקס = לחכות webhook” הוסכם.

רטריי עם גיבוי - רק לשגיאות זמניות. המטריצה הניתנת לניסוי/לא ניתנת לניסוי נדרשת.

נקודות סוף אופייניות (תרשימים וזרימה)

1) קלפים (ויזה/מאסטרקארד, וכו ')

POST/תשלומים - ליצור תשלום (”סכום”, ”מטבע”, ”payment _ token”, ”לכידה”).

POST/PROCRAD/ID/ 2 מאובטח בתלת מימד (אתגר/הפניה לאחור).

ללכוד לאחר אישור (חלקי/מלא).

החזר (בחלקים, עד לסכום המקורי).

קבל/תשלומים/* * * * * * * * * * * מורשה, נתפס, נכשל, requires_action).

3-D Secure/SCA: ספק יחזיר את 'requires _ action' + 'client _ secret '/URL לאתגר. לאחר אישור על ידי הלקוח, החזית תחזיר את התוצאה לחלק האחורי שלך.

2) A2A/Open Banking (תשלום באמצעות בנק)

תגובת POST/POLICTION = = תגובה מ-redirect _ url לבנק הלקוחות.

הלקוח מאושר ע "י הבנק * webhook 'payment. הצליח/נכשל '.

מצב סופי (לעתים קרובות רק אסינכרוני).

3) שיטות מקומיות (PIX, PAYD, FPX, IDEL וכו ').

POST/תשלומים _ get 'qr _ code '/' deflink '/' cofy _ code'.

הצג את המשתמש, המתן לבדיקת הרשת לגבי ההרשמה.

פסקי זמן של קוד וטי-טי-אל הם חלק מהחוזה.

4) תשלום

Post/payouts (”סכום”, ”מטבע”, ”יעד”).

GET/payouts/YID - ”Treathed” (”תור”, ”שלח”, ”שילם”, ”נכשל”).

אינטרנט 'out' payout. תשלום/כישלון הוא מקור האמת.

לולאה סגורה: עדיף לשלם למקור (היפוך) לפני החלופות.

Webhooks: ”מקור האמת”

אירועים: 'תשלום. תלוי/מורשה/נתפס/נכשל, 'תשלום. requires_action', החזר כספי. הצליח, 'תשלום. תשלום ”,” מחלוקת. נוצר ", וכו '.

משלוח: עם מגשים חתומים על ידי HMAC, לעתים קרובות ”לפחות פעם אחת”

התרגול הטוב ביותר: לעבד את webhook = לעדכן את החשבון = = להגיב 2xx. כל היגיון עסקי אחרי הוא אסינכרוני.

שגיאה ועיבוד מצב

קודי HTTP: '2xx' הצלחה; '4xx' טעות לקוח (אימות, הונאה/כשל בנק, אסימון שגוי); '5xx' - ספק.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

חלונות רדו: עבור 3DS - אתה לא יכול לחזור בך בלי סוף; עבור A2A - הפניה/קוד TTLs תקפים; עבור תשלום - לסגת.

אנטי-פראוד וסיכון

טביעת אצבעות התקן ונתונים התנהגותיים - באמצעות JS/SDK של הספק או השכבה שלך.

רשימות: סיכוני סל, רשימות שחור/לבן של שיטות/ASN/מדינות.

שערים מתכווננים: הגבלות על כלים חדשים, התקררות, מהירות, בדיקת סף RG/AML.

מדיניות: ”pass/step-up/hold/block” המבוססת על ניקוד + כללים.

מאפיינים על מסילות

כרטיסים: אישור נגד סליקה (כמות שניתן להזיז), 3DS2, החזר על העסקה המקורית, סכסוכים/שארזים.

בנקאות A2A/Open: הפניה/הזרמת הסכמה, אפרוב גבוה, עלות נמוכה; הכל אסינכרוני ותלוי מאוד בבנק.

מהירות מקומית: QR/כינוי, webhook מיידי, TTL והידור קפדני.

אתה צריך אסימונים לכרטיסים, תמיכה בכספים מהיצרן, בלי 3DS.

ורסינציה ותאימות

גרסאות API: '/v1 ',' גרסאות נתונים 'בכותרת או פישפלאגים.

שינויים אחורנית-תואמים: שדות לא-הרסניים בלבד.

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

יכולת תצפית ו ־ SLA

מטריצות: p95 אישור/זמן תשלום, אישור שיעור על ידי BIN/Bank/שיטה, נתח של מגשים מחדש, webhooks-lag.

יומנים: קורלציה על ידי ”בקשה _ id',” idempotency _ key ”,” תשלום _ id'.

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

סריקה וכספים

פנקס: כניסה כפולה, יומנים בלתי ניתנים לשינוי, ”מורשה/נתפס/מוחזר” סטטוסים.

הידור תלת-צדדי: ספר החשבונות שלך ↔ פנקסי אינטרנט ↔ דוחות ספק/בנק.

הפניות: שמור על ”despect _ reference”, ”network _ reference”, ”payout _ reference” - זה שומר את התמיכה.

ארגז חול, הסמכה וייצור

ארגז חול: אסימונים/כרטיסים/בנקים, סימולציה של 3DS/redirects, ”כפתורים” עבור מצבי webhook.

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

Go-Live: מפתחות Prod, domains webhook, IP-allowlist, לאפשר אנטי הונאה, להגדיר גבולות והתראות.

דוגמאות קטנות (סכמות)

צור תשלום (כרטיס)


פוסט/v1/תשלומים
{
”סכום”: 9232, ”מטבע”: ”EUR”, ”payment_method_token"”: ”pm_tok_123,” ”ללכוד”: נכון, ”metadata”:
}
▪ 200 ”id':” pay_abc, ”” סטטוס ”:” requires_action, ”” next_action" ”: [” type ”:” repression ”,” url': ”...”]

Webhook בהרשמה מוצלחת


POST/webhooks
{
”סוג”: תשלום. נתפסו, ”נתונים”: (”id':” pay _ abc ”,” כמות ”: 9232,” מטבע ”:” EUR ”,” metadata ”: [” סדר _ id': ”ORD-1001”]
}

תשלום @ action: inmenu


פוסט/V1/תשלום
{
”סכום”: 5000, ”מטבע”: ”EUR”, ”destination_token"”: ”dest_tok_456,” metadata ”: (” user _ id': ”u _ 77”)
}

רשימת בדיקות מימוש

1. ארכיטקטורת מפתח: סודות שרת בנפרד, סודות לקוח - חד פעמי.

2. Idempotency: בכל שיחה כתוב + idempotent webhook המפעילים.

3. חתימת HMAC, retrai, תור משימה, ניטור פיגור.

4. 3DS/SCA והפניות: טיפול ביטולים/פסקי זמן, מנסה חבר-UX שוב.

5. אנטי-פראוד/גבולות: מהירות, פרטים חדשים, רשימות שחורות, סף RG/AML.

6. פנקס ופיוס: כניסה כפולה, פיוס תלת-צדדי, התראות חריגות.

7. תזמור: ספק חילוף, ניתוב כללי על ידי BIN/country/sume.

8. ניטור: לוחות מחוונים מאשרים קצב/p95/מגשים מחדש, התראות על ידי בנקים/שיטות.

9. חוקי/PCI: אסימונים, מדיניות החזרה, לולאת תשלום סגורה.

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

טעויות תכופות

אחסון PAN על צידו ללא PCI ואסימונים.

אין אידמפוטנטיות * לשכפל תשלומים/תשלום עם פסקי זמן.

הגיון בתגובות סינכרוניות מבלי לקחת בחשבון פנקסי אינטרנט.

ספק אחד לשוק, בלי נסיגה/מפלים.

אין 3 DS לבטל/להפנות עיבוד = פחי מחזור אבודים.

צרור חלש = ”קפוא” ו ”אבוד” עסקאות.

היעדר סלבים ברורים והתראות = הבעיה שהלקוח רואה, לא אתה.

מיני ־ FAQ

שזה יותר אמין: סטטוס סינכרוני או ווב-הוק?

Webhook הוא מקור האמת; תגובה סינכרונית - רק ”פעולה מקובלת/נחוצה”.

אתה יכול להסתדר בלי 3-די-אס?

תלוי בתקנה/סיכון. ב EC/UK - SCA הוא חובה; עבור סיכון גבוה, צעד למעלה הוא טוב יותר.

איך להגדיל את שיעור האישור?

תזמור בנקים/שיטות, מסילות מקומיות, רטראס חכם, תיאורים נכונים, אנטי הונאה FPR נמוכה.

למה התשלום הוא ”לא מיידי”?

תלוי במסילה (OST/A2A/local), הבנק והמגבלות של הנמען. בואו נקבל חלון ישר של SLA וזרם מצב.

תשלומי API הם לא רק "ליצור תשלום. "משמעת זו: אימות מאובטח * okcenization = idempotency = asynchronous webooks = יומן מקפל = אנטי-הונאה/AML = תזמור וניטור. לבנות את התהליך על פי תוכנית זו, לשמור על ערוצים רזרביים ו-UX שקוף - ושכבת התשלום שלך תהיה מהירה, צפויה ועמידה בפני כשלים של בנקים וספקים.