Define why orchestration is needed
A layer between the product and payment providers can unify integrations, operational visibility and selected routing rules. It does not improve payment success by itself. Decide whether the problem is a single gateway outage, expansion into more markets, different payment methods, costs or difficult refunds. Each objective has a different measure. Adding a provider without a hypothesis creates more state and more opportunities for disagreement between systems.
Start with an inventory: who receives the instruction, who holds the transaction reference, who decides when an order is complete and who resolves an exception? Record methods, currencies, markets, customer types and boundaries between authorisation, capture, cancellation and refund. Provider products can have different rules. Orchestration should not pretend that all payments follow one universal lifecycle when the actual flows differ.
One business operation, several technical identifiers
Your system needs a stable internal payment identifier, while each processing attempt and provider may add its own reference. Keep their relationship explicit. An order, payment intent, attempt, authorisation and possible refund are different objects. Reducing them to one status field makes it hard to explain why a customer saw an error although funds moved, or why a second attempt created another authorisation. The model should reveal the sequence rather than hide it.
Design a state machine with permitted transitions and the source of each change. The user interface shows a derived view; it is not the only source of truth. Distinguish pending confirmation, rejected and unknown outcome. An unknown outcome calls for verification, not automatically creating a new payment. For each transition record time, original event, correlation identifier and the version of the rule that evaluated it. This evidence is useful during an incident and when reconciling records.
Routing requires rules and boundaries
A rule might select a provider by method, market, availability or an approved cost model. Define rule order, a default path and behaviour when information is missing. Availability alone should not trigger a switch: some failures concern the particular transaction, and retrying elsewhere may create a second attempt. A new path is safe only when the provider's actual statuses make the prior outcome clear enough. Treat ambiguous outcomes as exceptions until verified.
Version routing configuration. Store the version used and reason for the selection with each transaction so a later review can explain a difference between similar payments. Test new rules against suitable anonymised historical events, then on limited live traffic. Measure more than immediate approval: later refunds, exception handling cost and unresolved states matter too. A higher apparent success rate can merely move work to the back office if subsequent operations become harder.
Idempotency and timeouts govern retries
A network timeout means the client did not receive an answer; it does not establish whether the provider executed the request. Use a stable idempotency key for the same business operation where the particular API supports one. Adyen documents idempotent POST requests and a distinct response to a concurrent repeat. Check the provider's key lifetime and parameter rules before implementing retry. Generating a new key for an identical attempt can defeat the protection you expected.
A retry queue needs a bounded attempt count, spacing, visible status and a route to manual review. Distinguish connection errors, temporary unavailability and business rejection. A rejected customer method is usually not a technical failure that aggressive retry can repair. If the result remains ambiguous, retrieve the current state through a safe provider interface or place the case into a controlled exception queue. The customer should receive an honest pending message rather than false confirmation.
A webhook is evidence, not an unchecked command
An asynchronous notice can arrive more than once, late or in a different order from what the application expected. Adyen advises verifying the webhook's origin and integrity, storing it and acknowledging receipt before expensive business processing; it also documents duplicates. Build an ingress layer that checks signatures as that provider specifies, saves the original identifier and responds safely. Process the stored event idempotently afterwards and observe whether it was actually applied.
An event should not overwrite a payment regardless of current state. Map it to the internal identifier, check the permitted transition and open an exception on conflict. A late authorisation notice must not turn a completed refund back into a paid order. Retain the ability to replay stored input after a bug fix. Minimise personal and payment data in logs; operational monitoring usually needs a reference, event type and failed rule rather than sensitive payloads.
Reconciliation closes the gap between screen and money
The internal database, webhooks and provider statements may disagree temporarily. Reconciliation compares transactions through stable references, amount, currency, operation type and period. Define which discrepancies are expected delay and which are incidents. Track payments without an internal order, orders without a confirmed payment, duplicate authorisations and unexpected refunds separately. A dashboard without an owner for exceptions does not resolve any of them.
Daily or more frequent checks follow transaction volume and impact rather than a universal interval. Preserve evidence and human decisions for each exception. A correction should be repeatable and auditable: who approved it, what changed and whether the customer received accurate information. If a provider changes report structure, automated checks should fail visibly rather than silently interpret a missing column as zero.
Pilot and operational acceptance
Begin with one method, two clearly distinct paths and limited traffic. The test matrix should include success, rejection, timeout after submission, repeated request, duplicate and delayed webhook, partial outage and refund. Measure time to final state, unknown outcomes and time to resolve an exception. A live pilot needs a switch to disable new routing and return to a proven path. Failure exercises should use the same monitoring and staff that will handle production incidents.
Handover includes the state map, data contracts, keys and rotation, incident procedure, operational dashboard and owner of reconciliation. This page does not claim EXCOIN has a gateway partnership or a guaranteed improvement in approval rate. Provider choice and legal or security requirements must be checked for the particular business model. A useful first brief describes today's flow, known exceptions and why another route could yield measurable value.