Kako nastaviti samodejno polnjenje stanja v SMM-panelu prek API

Kaj pripraviti pred nastavitvijo samodejnega polnjenja

Samodejno polnjenje povezuje stanje SMM-panela s plačilno storitvijo ali notranjim obračunom. Storitev preveri preostanek, ustvari plačilo ob dosegu določenega praga in nakaže sredstva šele po potrditvi plačila. Za delovanje so potrebni dokumentacija API panela, dostop do plačilnega API, ločeni ključi za testno in delovno okolje ter dnevnik vseh operacij.

Pred razvojem preverite, ali API panela zna vrniti stanje, sprejeti zahtevo za nakazilo, prikazati zgodovino polnjenj in sprejeti zunanji identifikator operacije. Če panel ne podpira nakazila prek API, bo avtomatizacija lahko le ustvarila zahtevek ali poslala obvestilo operaterju. Pomanjkljivost te možnosti je, da bo denar vseeno treba vnesti ročno.

Ločite preverjanje stanja in odločitev o plačilu

Preverjanje preostanka je najbolje zagnati kot ločeno opravilo po urniku. Pridobi stanje, ga primerja s pragom in rezultat posreduje obdelovalcu polnjenja. Ne ustvarjajte plačila neposredno ob odgovoru API brez preverjanja trenutnih nedokončanih operacij: vzporedna opravila lahko vidijo isto nizko stanje in ustvarijo več plačil.

Pred novim plačilom mora obdelovalec preveriti, ali ne obstaja operacija s statusom »ustvarjena«, »čaka na plačilo« ali »se potrjuje«. Če tak zapis obstaja, se nov poskus ne zažene do zaključka usklajevanja. Pomanjkljivost zaporedne obdelave je, da se ob dolgem odgovoru zunanjega API polnjenje lahko začne pozneje kot pri več vzporednih zahtevah.

Izberite prag in logiko zneska polnjenja

Prag stanja izberite z rezervo za aktivna naročila, čakalno vrsto pri dobaviteljih in zamude pri plačilih. Za kanal z neenakomerno aktivnostjo je zanašanje le na povprečno porabo tvegano: po prenosu v živo, zagonu oglaševanja ali množičnem naročilu se lahko bremenitve močno povečajo. Ločeno se določi kritična raven, ob kateri pride obvestilo, vendar plačilo ni nujno ustvarjeno samodejno.

Znesek polnjenja je lahko fiksen ali izračunan iz porabe v izbranem obdobju. Fiksni znesek je preprostejši za nadzor in usklajevanje. Njegova pomanjkljivost je, da so v mirnem obdobju na stanju lahko odvečna sredstva, ob hitri rasti naročil pa eno polnjenje morda ne zadostuje. Izračunani znesek je prilagodljivejši, vendar zahteva čiščenje statistike od nenavadnih bremenitev in vračil.

Nastavite finančne omejitve ločeno od praga

Prag odgovarja le na vprašanje, kdaj sme sistem začeti postopek polnjenja. Omejitve odgovarjajo na drugo vprašanje: koliko sredstev sme bremeniti. Določite najvišji znesek posamezne operacije, skupno omejitev za obdobje in dopustni preostanek po nakazilu. Ta pravila se preverijo pred ustvarjanjem plačila, ne po njegovem plačilu.

Samodejno polnjenje ne sme bremeniti sredstev brez omejitve na operacijo in obdobje. Če je izračunani znesek višji od dovoljenega, je operacijo bolje preusmeriti v ročno preverjanje in poslati obvestilo. Pomanjkljivost togih omejitev je, da se ob hitri rasti stroškov stanje lahko izteče, preden odgovorni sodelavec potrdi povečanje omejitve.

Ustvarite ločene ključe in zaščitite dostop

Za skript samodejnega polnjenja uporabite ločene API-ključe z minimalnimi pravicami: branje stanja, ustvarjanje plačila, preverjanje statusa in nakazilo potrjene operacije. Dostop do uporabnikov, nastavitev storitev, naročil in izplačil sredstev tak ključ ne potrebuje. Če storitev podpira omejevanje po IP-naslovih, dovolite klice le s strežnika integracije.

Ključe hranite v okoljskih spremenljivkah ali zaščitenem shrambi skrivnosti. Ne posredujte jih v brskalniško kodo, dnevnike, javne repozitorije in sporočila o napakah. Vsak ključ mora imeti lastnika in jasen postopek zamenjave. Pomanjkljivost pogoste rotacije ključev je, da se polnjenje ustavi, če nove skrivnosti ne posodobite v vseh delovnih procesih.

Ustvarite plačilo z edinstvenim identifikatorjem

Vsakemu polnjenju se dodeli notranji identifikator pred klicem plačilnega API. Shrani se v dnevnik in posreduje kot ključ idempotentnosti ali zunanja številka operacije. Ob omrežni prekinitvi je mogoče isto zahtevo ponoviti z istim identifikatorjem: plačilna storitev mora vrniti že ustvarjeno operacijo, ne pa znova bremeniti denarja.

Spodaj je splošen primer zahteve. Imena polj in naslove zamenjajte z vrednostmi iz dokumentacije konkretnega ponudnika. V spremenljivki PAYMENT_ID je shranjen vnaprej ustvarjen edinstven ID, CALLBACK_URL pa vodi do obdelovalca spletnih kavljev.

curl -X POST "$PAYMENT_API_URL/payments" \
-H "Authorization: Bearer $PAYMENT_API_KEY" \
-H "Idempotency-Key: $PAYMENT_ID" \
-H "Content-Type: application/json" \
-d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID","callback_url":"$CALLBACK_URL"}'

Edinstvenosti plačila ne določajte le po znesku in času ustvarjanja. Dve enaki polnjenji sta lahko legitimni, ponovna zahteva po napaki pa ne. Pomanjkljivost zunanjega ID v lastni bazi je, da ga je treba zanesljivo hraniti in ga ne uporabiti znova po preklicu operacije.

Preverjajte stanje in shranjujte stanje operacije

Zahteva za stanje se mora izvesti pred odločitvijo o novem polnjenju in po uspešnem nakazilu. Splošna zahteva je lahko takšna: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY". V odgovoru shranite ne le znesek, ampak tudi čas preverjanja, da ne odločate na podlagi zastarelih podatkov.

Za vsako operacijo vodite zapis z notranjim ID, ID plačila pri ponudniku, zneskom, valuto, časom ustvarjanja, statusom, odgovori API in razlogom napake. Primerna veriga stanj: »ustvarjena«, »čaka na plačilo«, »plačana«, »se nakazuje«, »nakazana«, »preklicana«, »zahteva preverjanje«.

Nakazilo v panel je dovoljeno le za potrjeno in še ne obdelano plačilo. Statusov ne prepisujte brez zgodovine: ob sporu mora biti razvidno, katera zahteva je bila poslana in zakaj je bila operacija spremenjena. Pomanjkljivost podrobnega dnevnika je, da lahko vsebuje občutljive podatke, zato je dostop do njega omejen.

Sprejmite spletni kavelj in uskladite status plačila

Stran uspešnega plačila in preusmeritev uporabnika ne potrjujeta prejema denarja. Potrditev je spletni kavelj plačilne storitve ali ponovno preverjanje statusa prek njenega API. Ob prejemu spletnega kavlja preverite podpis, čas pošiljanja, ID plačila, zunanji ID, znesek in valuto. Šele nato operacijo prevedite v stanje potrjenega plačila.

Po preverjanju spletnega kavlja je koristno pri ponudniku zahtevati aktualni status plačila. Na primer: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY". Status uskladite s podatki v dnevniku, nato pošljite zahtevo za nakazilo v SMM-panel z istim notranjim ID.

Ponovni spletni kavelj ne sme ustvariti drugega nakazila. Obdelovalec najde operacijo po zunanjem ID, vidi status »nakazana« in vrne uspešen odgovor brez novih dejanj. Pomanjkljivost spletnih kavljev je, da se lahko zakasnijo ali ne prispejo, če obdelovalec ni bil dosegljiv.

Obvladajte prekinitve, ponovne poskuse in obtičala plačila

Ob prekinitvi po ustvarjanju plačila ne pošiljajte nove zahteve z drugim ID. Najprej poiščite operacijo po notranjem identifikatorju ali ponovite zahtevo z istim ključem idempotentnosti. Če je ponudnik sprejel prvotno zahtevo, bo vrnil obstoječe plačilo. To ščiti pred dvojno bremenitvijo ob prekinitvi povezave.

Če spletni kavelj ne prispe v določenem času, ozadno opravilo zahteva status plačila prek API. Ponovna preverjanja se izvajajo z naraščajočim premorom in omejenim številom poskusov, da ne preobremenijo API in dnevnika. Operacijo, ki dolgo ostane v čakanju, se preusmeri v ročno preverjanje, ne pa šteje za preklicano brez uskladitve.

Ob odgovorih o začasni omrežni napaki ali nedosegljivosti API so ponovni poskusi dopustni. Ob zavrnitvi plačila, napačnem znesku, neveljavnem podpisu spletnega kavlja ali preseganju omejitve zahteve ni treba samodejno ponavljati. Pomanjkljivost ponovnih poskusov je, da otežujejo logiko stanj in lahko ustvarijo odvečno obremenitev ob množični okvari pri ponudniku.

Nakažite potrjeno plačilo v SMM-panel

Pred nakazilom obdelovalec še enkrat preveri: znesek ne presega omejitve, valuta se ujema, operacija ni bila preklicana in njen status še ni »nakazana«. V zahtevo se posredujeta znesek in zunanji identifikator plačila. Če API panela podpira ključ idempotentnosti, uporabite isti notranji ID operacije.

Splošna oblika zahteve: curl -X POST "$PANEL_API_URL/balance/topups" -H "Authorization: Bearer $PANEL_API_KEY" -H "Content-Type: application/json" -H "Idempotency-Key: $PAYMENT_ID" -d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID"}'

Po odgovoru panela znova zahtevajte stanje in rezultat shranite v dnevnik. Če je denar bremenjen pri plačilni storitvi, API panela pa je vrnil napako, ne ustvarjajte novega plačila. Operacija ostane v statusu »zahteva preverjanje« do ponovnega poskusa nakazila ali ročne uskladitve. Pomanjkljivost takšne previdne sheme je, da se stanje morda začasno ne napolni samodejno.

Dodajte obvestila, stikalo za izklop in preverjanje zagona

Obvestila so potrebna ob odstopanjih: stanje je padlo pod kritično raven, plačilo je zavrnjeno, spletni kavelj ni prejet, omejitev je presežena, API ni dosegljiv ali operacija zahteva ročno preverjanje. V sporočilu zadošča navesti notranji ID, status in razlog. Ne vključujte vanj API-ključev, podpisov spletnih kavljev in plačilnih podatkov.

Pustite ločeno stikalo za izklop samodejnega polnjenja brez odstranitve integracije. Potrebno je ob menjavi ponudnika, tehničnih delih, sumu na napako ali nenadni spremembi stroškov. Pomanjkljivost stikala je očitna: če ga po delih ne vklopite nazaj, se lahko stanje izteče med aktivnimi naročili.

Kontrolni seznam pred vklopom samodejnega polnjenja

• Preverjanje stanja ne ustvari plačila, dokler obstaja nedokončana operacija.
• Za vsako plačilo se ustvari edinstven notranji ID in ključ idempotentnosti.
• Nastavljene so omejitve za posamezno operacijo in izbrano obdobje.
• Spletni kavlji se preverjajo po podpisu, znesku, valuti in identifikatorju.
• Ob odsotnosti spletnega kavlja se zažene ponovna uskladitev statusa prek API.
• Prekinitev ne privede do ustvarjanja drugega plačila pred preverjanjem prvega.
• Nakazilo v panel se izvede enkrat in se zabeleži v dnevnik.
• Testni način je preverjen ob uspehu, zavrnitvi, dvojniku spletnega kavlja in nedosegljivosti API.