Maksājumu API integrācija: dati, atkārtojumi un nodošana darbā

Modelējiet pasūtījumu un mēģinājumu atsevišķi

Pasūtījums apraksta pārdodamo pakalpojumu vai preci, bet maksājuma mēģinājumam ir savs tehniskais ceļš. Piešķiriet abiem stabilas atsauces un glabājiet saistību. Neskaidrs pasūtījuma stāvoklis nedrīkst pats radīt vēl vienu mēģinājumu. Nosakiet arī kontu, veikalu un vidi, ko pieprasījums izmantos. Ja ir vairāki veikali, izvēlei jābalstās uzticamos servera datos, ne tikai pārlūkā maināmā vērtībā. Skaidrs modelis ļauj vēlāk izskaidrot izmantoto konfigurāciju. Tas palīdz nodot gadījumu citai komandai, nesamazinot visu informāciju līdz summai, kas var atkārtoties daudzās neatkarīgās transakcijās.

Maksājumu API izstrādātājiem

Ievērojiet dokumentēto summas formātu

Katrs API nosaka savu vērtību pierakstu. Izmantojiet tieši šo vienošanos, nevis automātiski pārnesiet iepriekšējā sniedzēja konvenciju. OrsunPay dokumentē summas kā decimālas virknes. Pirms izsaukuma pārbaudiet valūtu un galīgo pasūtījuma versiju. Atlaidēm un izmaiņām jābūt ieviestām pirms pieprasījuma izveides. Izsekojiet vienam piemēram no komerciālajiem datiem līdz rezultātam un norādiet validācijas vietu. Pareizi izskatīga apmaksas lapa neizslēdz pārveidošanas kļūdu, ja sistēmas atšķirīgi interpretē skaitļus. Pierakstīta konvencija palīdz arī koda pārskatīšanā un pēc palaišanas konstatētu atšķirību izpētē.

Pievienojiet savus maksājumu pakalpojumus

Plānojiet pazudušu atbildi bez aklas atkārtošanas

Serveris var apstrādāt pieprasījumu, pat ja atbilde lietotnei nenonāk. Tādā brīdī vēl nav skaidrs, vai transakcija pastāv. Vēl viena izveide bez pārbaudes var radīt dublikātu. Lietojiet dokumentēto idempotenci un saglabājiet atslēgas saistību ar biznesa pieprasījumu. Atšķiriet tā paša izsaukuma atkārtojumu no apzināti jaunas maksājuma operācijas. Neļaujiet katram API klientam patstāvīgi izdomāt atjaunošanās stratēģiju pēc noildzes. Kopīgs noteikums samazina vienlaicīgus, pretrunīgus labošanas mēģinājumus un norāda procesu, kas atbild par nezināmā rezultāta noskaidrošanu. Šai rīcībai jābūt paredzētai pirms incidenta.

Savienojiet API rezultātu ar notikumu apstrādi

Izveides atbilde un vēlāk saņemts paziņojums var pildīt atšķirīgus uzdevumus. Dokumentējiet, kuri dati tiek saglabāti uzreiz un kā vēlāk atrod to pašu pasūtījumu. Servera notikumi jāautentificē un jāapstrādā bez dubultiem biznesa efektiem. Stripe un Mollie dokumentācija skaidro šo rezultāta dzīves ciklu. OrsunPay paziņojumiem ir dokumentēta HMAC-SHA256 pārbaude pār neizmainītiem ziņojuma baitiem. Slepenās atslēgas neievietojiet pārlūka kodā. Integrācijas plānā jābūt redzamam, kur beidzas pieprasījuma izveide un sākas tālāka, patstāvīga rezultāta uzraudzība un pasūtījuma stāvokļa atjaunināšana.

Nosakiet vienreizēju biznesa efektu

Pēc tehniskās pārbaudes lietotne izlemj atļauto stāvokļa pāreju. Viena un tā pati veiksmes informācija nedrīkst izraisīt divas piegādes vai aktivizācijas. Glabājiet apstrādes rezultātu tā, lai atkārtojums būtu atpazīstams bez atkārtotas darbības. Iekļaujiet arī novēlotus notikumus. Atgriešanās lapa var informēt klientu, bet pati nav samaksas pierādījums. Lēmumam par izpildi jābalstās pārbaudītā servera rezultātā un pasūtījuma noteikumos. Tādējādi process paliek korekts arī tad, kad pircējs neatgriežas lietotnē un nevar iesniegt nevienu ekrānuzņēmumu par redzēto soli.

Sagatavojiet nodošanu ikdienas darbam

Atbalstam nepieciešama meklējama atsauce un saprotams atvērtā gadījuma iemesls. Aprakstiet, kad drīkst atkārtot iekšēju apstrādi un kad jāsazinās ar PSP. OrsunPay savieno jūsu kontus, bet neaizstāj to nosacījumus vai apstiprināšanas lēmumus. Pirms SDK vai pakotnes iekļaušanas plānā apstipriniet tās publikāciju. Kods repozitorijā nepierāda publiskas pakotnes pieejamību. Nodošana ir noderīga, ja cits darbinieks ar paredzētajiem datiem spēj izmeklēt parauggadījumu un izskaidrot klientam zināmo posmu bez minējumiem. Tehniskajām un komerciālajām atsaucēm jāatbalsta viens saprotams lēmums.

• Simulējiet atbildes zudumu pēc operācijas izveides.
• Pārbaudiet summu, valūtu un veikala kontekstu.
• Nošķiriet atkārtotu pieprasījumu no jauna maksājuma.
• Aprakstiet rīcību nezināma rezultāta gadījumā.
• Izmantojiet kopīgas atsauces izstrādē un atbalstā.

Avoti

• Stripe dokumentācija par webhook paziņojumiem
• Mollie dokumentācija par maksājumu pieņemšanu