Payment gateway integration and technical failures
Design payment state, retries and reconciliation so a network error does not become a financial error.
Merchant payment challenges 08 / 10Inside this guide
Agree the payment lifecycle
Document how the application records a created, authenticated, authorized, captured, refunded or failed payment. Identify which system is authoritative at each stage. A browser success page alone should not be the finance team’s only evidence that a payment completed. Give support staff safe references they can trace across systems.
Treat timeouts as uncertain outcomes
A timeout does not establish that no payment occurred. Check the provider’s status and supported retry procedure before sending another request. Adyen documents idempotency for supported API calls so retries can avoid duplicate processing. Implement the exact provider mechanism and its limitations rather than assuming that an internal order number automatically provides this protection.
Test failure paths deliberately
Cover interrupted connections, delayed notifications, duplicate events, authentication cancellation, partial refunds and deployment rollbacks. Verify notification signatures and protect secrets using the provider’s documentation. Ensure repeated events do not repeatedly fulfill an order. Reconcile transactions and settlements even when automated messages are delayed or missing.
What it means for merchants
Assign a technical owner and agree the incident escalation route before launch. Monitor payment-state mismatches as well as uptime. A reliable integration is one that can establish what happened to both the customer’s order and the money when the happy path breaks.
Frequently asked questions
Can I retry a timed-out payment immediately?
First establish its status and follow the provider’s documented retry and idempotency behavior. An unknown outcome can otherwise become a duplicate payment.
Is a redirect success page enough to mark an order paid?
Use the provider’s documented server-side confirmation process and reconcile the state. A browser redirect can be interrupted or manipulated.
What is idempotency?
It is a supported mechanism for making repeated requests behave as one operation within documented conditions. Keys, scope and retention depend on the API.
Should duplicate webhooks be expected?
Build handlers to safely process repeated notifications according to the provider’s delivery contract, and verify authenticity before changing order state.
What should an incident report include?
Include timestamps, affected flows, safe references, observed states, recent releases and customer impact. Exclude passwords, API secrets and full card information.
When is an integration ready to launch?
After the agreed success and failure scenarios, reconciliation, refunds, monitoring and support handover have passed—not just one successful test purchase.
Sources
Merchant payment challenges
- 01Finding a merchant account for a high-risk business
- 02Merchant account freezes and terminated accounts
- 03Delayed payouts, rolling reserves and held funds
- 04High payment processing fees and hidden charges
- 05High card decline rates and low authorization rates
- 06Chargeback prevention and fraud management
- 07Cross-border payments and offshore merchant accounts
- 08Payment gateway integration and technical failures
- 09Recurring billing failures and subscription churn
- 10Finding alternative payment methods and backup processors
Payment Guide helps you research the structure, understand the questions and prepare your next conversation.