Sandboxové prostředí
Sandboxové prostředí Cardflo umožňuje vývojářům integrovat a testovat platební řešení bez ovlivnění živých transakcí. Tento izolovaný prostor zrcadlí naše produkční prostředí, což umožňuje důkladné testování všech funkcí Cardflo, od zpracování plateb po webhooky a interakce API, čímž je zajištěn hladký přechod na živé operace.
- Kategorie
- Vývojář
- Schopnosti
- 10
- Dostupné na
- Všechny plány
Přehled
Sandboxové prostředí funguje jako neprodukční instance platební brány nebo orchestrální platformy, která umožňuje vývojářům modelovat celý životní cyklus transakce bez přesunu reálných finančních prostředků. Funguje jako replika živého API, včetně komponent pro autorizaci, zachycení a vypořádání.
V rámci tohoto izolovaného kontejneru mohou technické týmy ověřit svou integrační logiku, struktury požadavků a ověřovací hlavičky proti přísným validačním pravidlům.
Použitím testovacích údajů a simulovaných čísel identifikace karty (BIN) mohou obchodníci vyhodnotit, jak jejich backend reaguje na různé odpovědi, jako jsou úspěšné platby, měkká zamítnutí nebo výzvy k ověření 3DS.
Sandbox se nachází mezi aplikací obchodníka a simulovaným akceptantem a poskytuje bezpečný prostor pro zajištění toho, že kód zvládá okrajové případy, jako jsou nedostatečné prostředky nebo expirované karty, před přechodem do živého produkčního prostředí,
kde by chyby mohly vést ke ztrátě příjmů nebo zvýšení poměru chargebacků.
Jak to funguje
Generování a ověření pověření
Vývojáři získají specifickou sadu klíčů API nebo Bearer tokenů určených pro testovací prostředí. Tyto pověření směrují požadavky na maketový procesor namísto živých platebních schémat.
Tím se zajišťuje, že se neúčtuje žádné identifikační číslo obchodníka (MID) za poplatky za zpracování a žádná reálná data držitele karty nevstupují do produkčních systémů.
Simulované zpracování transakcí
Obchodník odešle platební požadavek pomocí předdefinovaných čísel testovacích karet, která spouští specifické výsledky. Například použití jednoho BIN může simulovat úspěšnou autorizaci, zatímco jiné spustí neshodu CVV nebo tvrdé zamítnutí.
Sandbox vrací identickou strukturu JSON odpovědi jako živé API, aby byla zajištěna kompatibilita.
Oznámení událostí webhookem
Jakmile se v sandboxu změní stav transakce, systém vygeneruje asynchronní webhooky. Server obchodníka obdrží tato oznámení na určeném koncovém bodě, aby ověřil, že jeho systém správně aktualizuje interní databázi.
Tento krok je kritický pro testování logiky automatického plnění objednávek nebo správy předplatného v reálném čase.
Změna stavu a vypořádání
Uživatelé mohou ručně nebo programově převést stav transakce z autorizované na vypořádanou nebo vrácenou zpět v rámci testovacího panelu.
To umožňuje ověřit pracovní postupy po nákupu, včetně zpracování požadavků na vrácení peněz nebo částečných refundací, čímž se zajistí, že uživatelské rozhraní obchodníka odráží správný finanční stav.
Proč na tom záleží
Snížení rizika během nasazení
Implementace nových platebních toků přímo v produkci vytváří vysoké provozní riziko. Využitím sandboxu mohou vývojáři identifikovat logické chyby nebo špatně formátované požadavky API, které by jinak vedly k neúspěšným platbám.
Tato izolace chrání integritu živého identifikačního čísla obchodníka a zabraňuje náhodnému spuštění anti-podvodných filtrů, ke kterému by mohlo dojít během agresivního testování nové logiky integrace platby s kartou nebo bez karty.
Ověření složité logiky
Moderní platby často zahrnují vícestupňové procesy, jako je silné ověření zákazníka (SCA) nebo opakované fakturace. Sandbox umožňuje důkladné testování transakcí iniciovaných držitelem karty a obchodníkem bez finančních nákladů na skutečné transakce.
Zajišťuje, že systém správně interpretuje různé kódy zamítnutí a zprávy odpovědí od vydavatelů, což umožňuje zdokonalení logiky upomínek a strategií opakování pro optimalizaci konečných konverzních poměrů.
Případy použití
Počáteční integrace API
Noví obchodníci používají sandbox k mapování svých interních systémů pro správu objednávek na koncové body API platební brány. Tím se potvrdí, že datová pole, jako jsou kódy měn a kódy obchodních kategorií, jsou správně formátována pro autorizaci.
Ověření opakované fakturace
Podniky založené na předplatném testují své sekvence pro upomínky platby simulací vypršení platnosti karty nebo nedostatečných finančních prostředků. Tím se zajišťuje, že systém správně provede opakované pokusy a odešle příslušná oznámení zákazníkovi před pozastavením služby.
Ladění koncových bodů webhooků
Vývojáři používají testovací prostředí k ověření, že jejich konfigurace firewallu a serveru umožňují příchozí oznámení webhooků. Tím se předchází problémům, kdy objednávky zůstávají „čekající“, přestože byly úspěšně autorizovány na úrovni akceptanta.
Testování alternativní platební metody
Před povolením místních platebních metod mohou obchodníci simulovat přesměrovací toky potřebné pro APM. Tím se zajišťuje, že uživatelský zážitek zůstane konzistentní, když je zákazník odeslán na peněženku třetí strany nebo bankovní portál.
V číslech
Typické zvýšení efektivity, které technické týmy zaznamenávají při používání komplexního sandboxu ve srovnání s manuálním procházením dokumentace a přímým produkčním testováním.
Odhadovaný rozsah snížení počtu chyb po nasazení souvisejících s platební logikou, pokud je součástí CI/CD pipeline implementováno důkladné testování v sandboxovém prostředí.
Standardní průmyslová doba odezvy pro mock API endpointy, umožňující rychlou iteraci během životního cyklu vývoje softwaru.
Související pojmy
Talk to our team about a live rollout on your acquiring stack.
What you get with Sandboxové prostředí
- Ověřte struktury požadavků a odpovědí API proti oficiální dokumentaci v zabezpečeném prostředí.
- Simulujte specifické důvody zamítnutí autorizace pro ověření zpracování chyb a zpráv zákazníkům.
- Spouštějte a přijímejte oznámení webhooky o aktualizacích stavu, jako je zachycení, vrácení peněz a spor.
- Testujte toky ověřování 3-D Secure pro zajištění souladu s PSD2 a požadavky SCA.
- Ověřte zpracování síťových tokenů a oznámení o aktualizacích účtů bez reálných dat.
- Proveďte zátěžové testování integrační logiky před přechodem do produkčních prostředí s vyšším objemem.
- Konfigurujte více obchodních profilů pro testování konverze měn a domácího versus mezinárodního zpracování.
- Auditujte záznamy ID transakcí, ARN a časových značek pro interní finanční odsouhlasení.
- Modelujte chování částečných zachycení a vícenásobných vrácení peněz na jedné transakci.
- Prostudujte dopad kódů obchodních kategorií na simulované míry autorizace a struktury poplatků.
A short scoping call, then a written plan for your MIDs.
Questions about Sandboxové prostředí
Objevují se sandboxové transakce na skutečných bankovních výpisech nebo vznikají poplatky za schéma?
Ne, transakce zpracované v sandboxovém prostředí neinteragují se skutečnými platebními schématy, jako je Visa nebo Mastercard. Jsou zpracovávány maketovým procesorem, který simuluje odezvu vydavatele.
V důsledku toho se nepřesouvají žádné skutečné finanční prostředky, držiteli karty nejsou účtovány žádné poplatky a obchodníkovi nevznikají žádné mezibankovní poplatky ani poplatky za schéma. Prostředí je zcela izolované, aby se zabránilo finančnímu dopadu.
Mohu testovat silné ověření zákazníka (SCA) a 3D Secure v sandboxu?
Ano, vysoce kvalitní sandboxová prostředí poskytují specifické testovací karty nebo příznaky pro spuštění toků 3DS. To umožňuje vývojářům otestovat přesměrování na simulovaný Access Control Server (ACS) a zpracovat výsledné výsledky ověření, jako je úspěch, selhání nebo obejití.
Jedná se o nezbytný krok pro evropské obchodníky, aby zajistili soulad s PSD2 požadavky na elektronické platby.
Jak simulovat tvrdé zamítnutí (hard decline) versus měkké zamítnutí (soft-decline) při testování?
Simulace se obvykle dosahuje pomocí různých testovacích čísel karet nebo částek transakcí specifikovaných v dokumentaci. Konkrétní BIN může být mapován na odpověď 'Ztracená nebo odcizená karta' (tvrdé zamítnutí), zatímco jiný může spustit 'Nedostatečné prostředky' (měkké zamítnutí).
Testování těchto variant je pro vývojáře klíčové pro implementaci správné logiky opakovaných pokusů a pro rozlišení mezi trvalými a dočasnými selháními.
Podléhají uložená data držitelů karet v sandboxu dodržování PCI-DSS?
Zatímco sandbox by neměl obsahovat žádná reálná data držitelů karet, bezpečnost API klíčů a simulovaných dat zůstává důležitá. Většina sandboxových prostředí používá pseudosměrná data, která připomínají reálná čísla PAN, ale nedaří se jim projít kontrolami Luhnova algoritmu nebo patří do nepřidělených rozsahů.
Vývojáři by však měli dodržovat dobré bezpečnostní postupy a nikdy nepoužívat reálná zákaznická data v testovacím prostředí, aby se vyhnuli potenciálním rizikům úniku dat.
Obdrží můj koncový bod webhooku stejnou datovou zprávu jako produkční prostředí?
JSON nebo XML datová zpráva doručená na vaši webhook URL v sandboxovém prostředí by měla přesně zrcadlit produkční schéma. To zahrnuje stejná pole pro ID transakce, částku, měnu a stavové kódy.
Testování tímto způsobem zajišťuje, že váš backendový parser je správně nakonfigurován pro zpracování živého datového toku, aniž by bylo nutné provádět změny kódu během přechodu do produkce.
Mohu otestovat proces vypořádání a odsouhlasení v sandboxu?
Můžete simulovat přechody, které vedou k vypořádání, například přesun transakce z 'autorizované' na 'zachycenou'. Některé sandboxové prostředí vám umožňují generovat falešné zprávy, které se podobají souborům vypořádání poskytovaným akceptanty.
To pomáhá při vytváření automatizovaných nástrojů pro odsouhlasení, které odpovídají interním ID objednávek s transakčními referencemi poskytovanými poskytovatelem platebních služeb.
Související funkce.
Připraveni na rychlost?
Řekněte nám o svém podnikání. Spojíme vás s těmi správnými akvizičními partnery a správnou cestou, obvykle do týdne.