A payment orchestration migration plan for an existing checkout

Document the current payment lifecycle

Draw the journey from order creation to provider settlement before designing the replacement. Include authorisation or payment initiation, customer authentication, notifications, fulfilment, refunds and reporting. List every system that consumes payment status, including less visible jobs such as warehouse exports or support dashboards. For each transition, identify the evidence that currently permits the next action. If a browser redirect has been treated as confirmation, mark that as a design problem to resolve. Carrying an unreliable assumption into a new platform merely changes where the problem appears.

Payment orchestration

Define a stable mapping of identifiers

Create a mapping between your order reference, the orchestration transaction and the provider transaction. Preserve historical provider references so support can still investigate payments made before the migration. Avoid overwriting an old identifier when a new attempt starts. Consider an order that was initiated before the cutover but completes afterwards: its event must reach the correct order regardless of which integration created it. Document where each identifier is stored, which system is authoritative and how staff search for it. This becomes the foundation for later reconciliation.

Provider connections

Compare supported capabilities account by account

A provider name in an integration catalogue does not establish that every method, currency or operation is available for your account. Build a matrix of the capabilities actually needed for launch and confirm them against the integration and provider setup. Distinguish essential payment creation and status retrieval from optional capabilities such as refunds or specialised payment methods. Keep unsupported requirements visible instead of assuming the orchestration layer will supply them automatically. Merchant eligibility and settlement arrangements remain questions for the provider, while software integration scope must be agreed separately.

Cut over a controlled portion of traffic

Choose a small, identifiable launch scope, such as one shop or a defined payment method, and keep the previous path available for the remaining scope. A pilot should have a clear owner and observable completion criteria. Do not send the same customer request to two payment paths merely to compare results. Instead, use isolated test scenarios and then a controlled live rollout. Decide in advance how new orders return to the previous integration if the pilot fails, while preserving the ability to receive final events for transactions already created.

• Define the pilot population and its owner.
• Keep old transaction references searchable.
• Separate rollback of new orders from completion of existing payments.
• Record a decision threshold for expanding the rollout.

Reconcile the first operational cycle

Check the pilot at the end of an actual operating cycle rather than only after the first successful payment. Compare orders, verified payment records and provider reports. Inspect abandoned attempts, duplicated notifications and operations still waiting for a final status. Ask support staff to investigate a sample transaction using the new identifiers. A migration is incomplete if engineers can trace a payment but the operational team cannot. Keep discrepancy notes with an owner and resolution so the decision to expand is supported by evidence rather than a favourable headline total.

Understand the OrsunPay boundary

OrsunPay provides a common workflow for configured provider connections, statuses and signed notifications. It does not replace the merchant's PSP contracts or settle funds itself. Current provider selection follows configured connections and eligible hosted-checkout methods; automatic cascading and cost-optimisation routing are not available today. That makes a precise migration scope especially important. The initial success criterion should be reliable creation, confirmation and investigation of supported payments. Any later routing ambition needs its own confirmed capability, risk assessment and implementation plan rather than being assumed from the word orchestration.

Sources

• Stripe — Payments
• Stripe — Webhooks