WooCommerce a platební brána: integrační kontrolní seznam

Popište konfiguraci a vzorové košíky

Zapište verze WordPressu a WooCommerce, motiv a rozšíření měnící košík nebo checkout. Přidejte měny, trhy a typy objednávek. Připravte běžný nákup i příklad se slevou nebo změnou dopravy. Dodavatel má odpovědět pro tuto sestavu, nikoli pouze pro čistou demonstrační instalaci. Ujasněte si, kdo modul udržuje a jaká kompatibilita je doložena. Když aktualizace změní průběh, tým musí znát správného partnera pro řešení. Takový přehled umožní porovnávat stejné požadavky a předejde pozdějším neshodám o tom, co vlastně mělo být součástí nasazení.

Obchodní moduly — Soon

Oddělte plugin a oprávnění poskytovatelského účtu

Plugin propojuje systémy, zatímco PSP určuje podmínky účtu, přijetí obchodníka a dostupné metody. Ověřte obě vrstvy před plánováním spuštění. Přepínač v nastavení nedokazuje, že metoda funguje pro vaši firmu a měnu. Označte také přístupové údaje testovacího a živého prostředí. U více obchodů udržujte jednoznačné přiřazení ke správnému kontextu. Drobná konfigurační změna nesmí vést k použití nesprávného účtu nebo společnosti. Technicky aktivovaný modul proto není dokončenou přejímkou; potřebujete ověřený průběh pro skutečné obchodní údaje a zamýšlené použití.

Integrace a API

Definujte přechody stavů objednávky

Napište, co má WooCommerce provést po potvrzení, při čekání a při potřebě dalšího ověření. Návrat prohlížeče není dostatečný důkaz úhrady. Integrace má používat serverové výsledky a tolerovat opakovaná oznámení. Stripe a Mollie tento princip popisují ve svých dokumentacích. Zkontrolujte, že pozdní událost dorazí ke správné objednávce a duplikát nespustí další zásilku nebo aktivaci. Pravidla musí být pochopitelná i pro zákaznickou podporu. Ta bude vysvětlovat průběh klientovi a neměla by kvůli každému dotazu ručně interpretovat technické logy nebo pořadí otevřených stránek.

Hostovaná platební stránka

Ujasněte si skutečný rozsah následných operací

Zeptejte se, které činnosti po nákupu existují v modulu a které se provádějí v jiném rozhraní. Storno objednávky v e-shopu nemusí znamenat vrácení transakce poskytovatelem. Uchovejte reference obou kroků a jejich výsledky. Přidělte oprávnění a schvalovatele podle svého procesu. Pokud stejný požadavek řeší více pracovníků, viditelná historie zabrání dvojímu provedení. Ověřte také vyhledávání podle obchodní reference. Provoz by neměl být závislý na ručním procházení seznamu částek a dat, zvlášť když stejnou službu kupuje mnoho zákazníků.

Připravte aktualizaci a řešení výpadku

Přejímka má zahrnovat úspěch, uzavřené okno, neznámý výsledek a opakované oznámení. Potom určete, jak aktualizovat modul při existujících otevřených objednávkách. Návrat předchozí verze kódu neodstraní už založenou transakci. Vyberte osobu rozhodující o zastavení nových požadavků a postup kontroly starších případů. Zapsaná pravidla omezují improvizované výzvy k další platbě, když první výsledek není jasný. Každý opravný postup má zachovat historii a umožnit určit, co bylo skutečně provedeno. Bez toho se technický zásah může změnit v nový obchodní problém.

Nezaměňujte plánovanou publikaci za dostupnost

Commerce pluginy OrsunPay včetně WooCommerce jsou na roadmapě a jejich veřejné vydání není potvrzené. Nejde o nabídku stažení ani všeobecnou záruku kompatibility. Budoucí verzi bude nutné posoudit podle doloženého rozsahu. Samostatně dohodnutá integrace pomocí dostupných nástrojů je jiná zakázka. OrsunPay zachovává vlastní účty a smlouvy PSP obchodníka; nezajišťuje automatické přijetí firmy ani dnes automatické kaskády mezi poskytovateli. Termín spuštění proto odvozujte od potvrzených funkcí a dokončené přejímky, nikoli od obrázku nebo názvu plánovaného produktu.

• Zapište verze platformy, motiv a doplňky checkoutu.
• Potvrďte rozsah používaného PSP účtu.
• Spojte každý výsledek s konkrétní akcí objednávky.
• Oddělte storno objednávky a vrácení platby.
• Určete odpovědnost za aktualizaci i návrat změny.

Zdroje

• Dokumentace Stripe k webhookům
• Dokumentace Mollie k platbám