When evaluating a payment interface, do not start from provider name. Start from actions the business must perform: payment page, website sale, recurring charge, void, refund, instalments, reference,...
When evaluating a payment interface, do not start from provider name. Start from actions the business must perform: payment page, website sale, recurring charge, void, refund, instalments, reference, settlement, and reconciliation. For every action, define the success event, transaction identifier, and outcome when a response does not return to the site.
The checkout or website should retain a payment attempt before calling the provider. In a timeout, staff can check the transaction by ID rather than send another charge. “Unknown state” is a valid result until it is resolved with the provider or transaction report.
Because payments involve sensitive information, do not retain card details in application code or database without an explicitly defined provider-approved route. Use the provider mechanism and define who may view reports, issue a refund, or rotate access credentials.
Sources
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.