Hogyan állítsuk be az automatikus egyenlegfeltöltést az SMM-panelben API-n keresztül

Mit kell előkészíteni az automatikus feltöltés beállítása előtt

Az automatikus feltöltés összekapcsolja az SMM-panel egyenlegét egy fizetési szolgáltatással vagy belső számlázással. A szolgáltatás ellenőrzi az egyenleget, fizetést hoz létre a megadott küszöb elérésekor, és csak a fizetés visszaigazolása után írja jóvá az összeget. A működéshez szükség van a panel API-dokumentációjára, hozzáférésre a fizetési API-hoz, külön kulcsokra a teszt- és az éles környezethez, valamint az összes művelet naplójára.

A fejlesztés előtt ellenőrizze, hogy a panel API-ja képes-e visszaadni az egyenleget, fogadni a jóváírási kérelmet, megjeleníteni a feltöltési előzményeket és fogadni a külső műveletazonosítót. Ha a panel nem támogatja az API-n keresztüli jóváírást, az automatizálás csak kérelmet tud létrehozni vagy értesítést küldeni az operátornak. Ennek a megoldásnak a hátránya, hogy a pénzt így is manuálisan kell befizetni.

Válassza szét az egyenlegellenőrzést és a fizetési döntést

Az egyenleg ellenőrzését érdemes külön, ütemezett feladatként futtatni. Ez lekéri az egyenleget, összehasonlítja a küszöbbel, és az eredményt átadja a feltöltéskezelőnek. Ne hozzon létre fizetést közvetlenül az API-válasz pillanatában a folyamatban lévő műveletek ellenőrzése nélkül: a párhuzamos feladatok ugyanazt az alacsony egyenleget láthatják, és több fizetést is létrehozhatnak.

Új fizetés előtt a kezelőnek ellenőriznie kell, hogy nincs-e „létrehozva”, „fizetésre vár” vagy „megerősítés alatt” állapotú művelet. Ha van ilyen bejegyzés, az új kísérlet nem indul el az egyeztetés befejezéséig. A soros feldolgozás hátránya, hogy a külső API lassú válasza esetén a feltöltés később indulhat, mint több párhuzamos kérés esetén.

Válassza ki a küszöböt és a feltöltési összeg logikáját

Az egyenlegküszöböt az aktív rendelések, a beszállítói sor és a fizetési késedelmek tartalékával érdemes megválasztani. Egy egyenetlen aktivitású csatornánál kockázatos csak az átlagos kiadásra támaszkodni: egy stream, egy hirdetésindítás vagy egy tömeges rendelés után a terhelések hirtelen megnőhetnek. Külön kell megadni egy kritikus szintet, amelynél értesítés érkezik, de a fizetés nem feltétlenül jön létre automatikusan.

A feltöltési összeg lehet fix vagy a kiválasztott időszak kiadásaiból számított. A fix összeg egyszerűbb az ellenőrzéshez és az egyeztetéshez. Hátránya, hogy nyugodt időszakban felesleges pénz maradhat az egyenlegen, míg a rendelések hirtelen növekedésekor egy feltöltés nem biztos, hogy elég. A számított összeg rugalmasabb, de a statisztikát meg kell tisztítani a rendellenes terhelésektől és visszatérítésektől.

Állítsa be a pénzügyi korlátokat a küszöbtől külön

A küszöb csak arra a kérdésre válaszol, mikor engedélyezett a rendszernek a feltöltési folyamat elindítása. A korlátok egy másik kérdésre válaszolnak: mennyi pénzt jogosult terhelni. Adjon meg maximális összeget egy műveletre, teljes limitet az időszakra és a jóváírás után megengedett egyenleget. Ezeket a szabályokat a fizetés létrehozása előtt kell ellenőrizni, nem a kifizetése után.

Az automatikus feltöltés nem terhelhet pénzt műveleti és időszaki limit nélkül. Ha a számított összeg meghaladja az engedélyezettet, a műveletet jobb manuális ellenőrzésre átadni és értesítést küldeni. A szigorú limitek hátránya, hogy a kiadások gyors növekedésekor az egyenleg elfogyhat, mielőtt a felelős munkatárs megerősíti a limit emelését.

Hozzon létre külön kulcsokat és védje a hozzáférést

Az automatikus feltöltési szkripthez használjon külön API-kulcsokat minimális jogosultságokkal: egyenleg olvasása, fizetés létrehozása, állapot ellenőrzése és a megerősített művelet jóváírása. A felhasználókhoz, szolgáltatásbeállításokhoz, rendelésekhez és pénzkivonáshoz ilyen kulcsnak nem kell hozzáférnie. Ha a szolgáltatás támogat IP-cím szerinti korlátozást, csak az integrációs szerverről engedélyezze a hozzáférést.

A kulcsokat környezeti változókban vagy védett titoktárban kell tárolni. Ne adja át őket böngészőkódban, naplókban, nyilvános tárolókban és hibaüzenetekben. Minden kulcsnak legyen tulajdonosa és egyértelmű csereeljárása. A gyakori kulcsrotáció hátránya, hogy a feltöltés leáll, ha az új titkot nem frissítik minden munkafolyamatban.

Hozzon létre fizetést egyedi azonosítóval

Minden feltöltéshez belső azonosítót kell rendelni a fizetési API hívása előtt. Ezt el kell menteni a naplóba, és át kell adni idempotenciakulcsként vagy külső műveletszámként. Hálózati időtúllépés esetén ugyanaz a kérés megismételhető ugyanazzal az azonosítóval: a fizetési szolgáltatásnak a már létrehozott műveletet kell visszaadnia, nem pedig újra terhelnie a pénzt.

Az alábbi egy általános kérési példa. A mezőneveket és a címeket cserélje ki az adott szolgáltató dokumentációjában szereplő értékekre. A PAYMENT_ID változóban egy előre létrehozott egyedi ID található, a CALLBACK_URL pedig a webhookkezelőre mutat.

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"}'

Ne határozza meg a fizetés egyediségét csak az összeg és a létrehozási idő alapján. Két azonos feltöltés lehet jogszerű, de egy hiba utáni ismételt kérés nem. A saját adatbázisban tárolt külső ID hátránya, hogy megbízhatóan kell tárolni, és a művelet törlése után nem szabad újra felhasználni.

Ellenőrizze az egyenleget és mentse a művelet állapotát

Az egyenleglekérést az új feltöltésről szóló döntés előtt és a sikeres jóváírás után is végre kell hajtani. Egy általános kérés így nézhet ki: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY". A válaszban ne csak az összeget mentse el, hanem az ellenőrzés idejét is, hogy ne elavult adatok alapján döntsön.

Minden művelethez vezessen bejegyzést belső ID-val, a szolgáltatónál lévő fizetési ID-val, összeggel, pénznemmel, létrehozási idővel, állapottal, API-válaszokkal és a hiba okával. Egy megfelelő állapotsor: „létrehozva”, „fizetésre vár”, „kifizetve”, „jóváírás alatt”, „jóváírva”, „törölve”, „ellenőrzést igényel”.

A panelbe történő jóváírás csak megerősített és még nem feldolgozott fizetés esetén engedélyezett. Ne írja át az állapotokat előzmények nélkül: vita esetén látszania kell, milyen kérés ment ki, és miért változott meg a művelet. A részletes napló hátránya, hogy érzékeny adatokat tartalmazhat, ezért a hozzáférést korlátozni kell.

Fogadja a webhookot és egyeztesse a fizetés állapotát

A sikeres fizetési oldal és a felhasználó átirányítása nem igazolja a pénz beérkezését. A visszaigazolást a fizetési szolgáltatás webhookja vagy az állapot ismételt ellenőrzése adja az API-ján keresztül. A webhook fogadásakor ellenőrizze az aláírást, a küldés idejét, a fizetési ID-t, a külső ID-t, az összeget és a pénznemet. Csak ezután állítsa a műveletet megerősített fizetési állapotba.

A webhook ellenőrzése után érdemes lekérni a fizetés aktuális állapotát a szolgáltatótól. Például: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY". Hasonlítsa össze az állapotot a napló adataival, majd küldje el a jóváírási kérést az SMM-panelnek ugyanazzal a belső ID-val.

Az ismételt webhook nem hozhat létre második jóváírást. A kezelő megtalálja a műveletet a külső ID alapján, látja a „jóváírva” állapotot, és új műveletek nélkül sikeres választ ad. A webhookok hátránya, hogy késhetnek vagy elmaradhatnak, ha a kezelő elérhetetlen volt.

Kezelje az időtúllépéseket, az újrapróbálkozásokat és a beragadt fizetéseket

A fizetés létrehozása utáni időtúllépés esetén ne küldjön új kérést más ID-val. Először keresse meg a műveletet a belső azonosító alapján, vagy ismételje meg a kérést ugyanazzal az idempotenciakulccsal. Ha a szolgáltató elfogadta az eredeti kérést, a meglévő fizetést adja vissza. Ez véd a kétszeres terhelés ellen kapcsolatszakadás esetén.

Ha a webhook nem érkezett meg a megadott időn belül, egy háttérfeladat lekéri a fizetés állapotát az API-n keresztül. Az ismételt ellenőrzéseket növekvő szünettel és korlátozott számú kísérlettel kell végezni, hogy ne terheljék túl az API-t és a naplót. A sokáig várakozó műveletet manuális ellenőrzésre kell átadni, nem pedig egyeztetés nélkül töröltnek tekinteni.

Átmeneti hálózati hiba vagy az API elérhetetlensége esetén az újrapróbálkozások megengedettek. Fizetési elutasítás, hibás összeg, érvénytelen webhook-aláírás vagy limit túllépése esetén nem érdemes a kérést automatikusan megismételni. Az újrapróbálkozások hátránya, hogy bonyolítják az állapotlogikát, és a szolgáltatónál bekövetkező tömeges hiba esetén felesleges terhelést okozhatnak.

Írja jóvá a megerősített fizetést az SMM-panelben

A jóváírás előtt a kezelő még egyszer ellenőrzi: az összeg nem haladja meg a limitet, a pénznem megegyezik, a műveletet nem törölték, és az állapota még nem „jóváírva”. A kérésben át kell adni az összeget és a fizetés külső azonosítóját. Ha a panel API-ja támogat idempotenciakulcsot, használja ugyanazt a belső műveleti ID-t.

A kérés általános formája: 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"}'

A panel válasza után kérje le ismét az egyenleget, és mentse el az eredményt a naplóba. Ha a pénzt a fizetési szolgáltatás terhelte, de a panel API-ja hibát adott vissza, ne hozzon létre új fizetést. A művelet „ellenőrzést igényel” állapotban marad a jóváírás ismételt kísérletéig vagy a manuális egyeztetésig. Az ilyen óvatos séma hátránya, hogy az egyenleg átmenetileg nem töltődhet fel automatikusan.

Adjon hozzá értesítéseket, kapcsolót és indításellenőrzést

Értesítések az eltérésekhez kellenek: az egyenleg a kritikus szint alá esett, a fizetést elutasították, a webhook nem érkezett meg, a limitet túllépték, az API elérhetetlen, vagy a művelet manuális ellenőrzést igényel. Az üzenetben elég megadni a belső ID-t, az állapotot és az okot. Ne tartalmazzon API-kulcsokat, webhook-aláírásokat és fizetési adatokat.

Hagyjon külön kapcsolót az automatikus feltöltéshez az integráció törlése nélkül. Erre szolgáltatóváltáskor, karbantartáskor, hiba gyanúja esetén vagy a kiadások hirtelen változásakor van szükség. A kapcsoló hátránya nyilvánvaló: ha a munka után nem kapcsolja vissza, az egyenleg elfogyhat az aktív rendelések közben.

Ellenőrzőlista az automatikus feltöltés bekapcsolása előtt

• Az egyenlegellenőrzés nem hoz létre fizetést, amíg van befejezetlen művelet.
• Minden fizetéshez egyedi belső ID és idempotenciakulcs jön létre.
• Be vannak állítva a limitek egy műveletre és a kiválasztott időszakra.
• A webhookokat aláírás, összeg, pénznem és azonosító alapján ellenőrzik.
• Webhook hiányában elindul az állapot ismételt egyeztetése az API-n keresztül.
• Az időtúllépés nem vezet második fizetés létrehozásához az első ellenőrzése előtt.
• A panelbe történő jóváírás egyszer történik meg, és rögzítésre kerül a naplóban.
• A tesztmódot siker, elutasítás, ismételt webhook és az API elérhetetlensége esetén is ellenőrizték.