Prepared by MagicPay, this guide helps businesses choosing payment infrastructure separate connectivity from decision-making and operations. It follows a payment from the provider request to the confirmed outcome in order and finance records. It presents MagicPay's perspective as a technology provider and offers a decision framework for evaluating your project.
1. Separate connectivity from coordination by function
A payment gateway is the connectivity layer that translates a business's payment request into a provider's format, sends it and carries the response back. Payment orchestration coordinates which eligible connection to use, what to do with the outcome and how to track the process. These are not mutually exclusive product categories: a gateway may also offer routing and operational functions. Identify the boundary through ownership of each step, not the product name.
- Connectivity question: Under which API contract is the request sent, and to which provider?
- Orchestration question: Why was that connection selected, and which outcome determines the next step?
2. Map the payment journey of one order
Create order and payment references, select an eligible connection and send the request. Depending on the flow, the customer may need to complete authentication; the outcome may arrive immediately or remain pending. Reaching the customer return page is not sufficient proof of payment. A verified server notification or documented status query updates the payment state. Authorisation, capture and settlement can be separate stages; tie fulfilment to the appropriate confirmed stage.
3. Start routing with eligibility conditions
Routing determines which provider to use before an attempt begins. Currency, payment method, merchant account and provider agreement first restrict the eligible options; priority or cost rules operate within that set. Having several connections does not itself mean a usable fallback exists. When evaluating a routing rule, ask when it applies, where its decision is recorded and who can roll it back if it behaves incorrectly.
4. Resolve uncertain outcomes before retrying
A timeout does not prove that a provider failed to process the request. Record the existing attempt, then query its status using the provider reference or wait for a verified notification. Sending a fresh charge to another provider while the first outcome is unknown can produce two successful payments. When technically resending the same request, follow the provider's idempotency contract: reuse its operation key and parameters only within the supported scope and retention window. A key at one provider does not deduplicate a transaction at another.
- Distinguish temporary communication failures from definitive declines; not every decline is retryable.
- Start a new attempt only when the previous outcome and provider rules permit it; define attempt and waiting limits.
- If uncertainty remains, send the payment for investigation; generating a new key does not resolve its status.
5. Design operational records separately from the payment response
Keep the order reference, each attempt ID, provider reference, amount, currency, decision reason and state transitions traceable together. Verify notifications using the provider's method; prevent duplicate or out-of-order events from completing an order twice. This operational record is not a substitute for an accounting ledger or bank reconciliation. Track a refund request separately from a completed refund, and a successful charge separately from settled funds. Assign ownership of differences between order, provider and finance records.
6. Choose the layer your workload needs
For a business with one provider and a clear status flow, connectivity and basic state tracking may be sufficient. Multiple providers, changing routing rules, unresolved-payment queues or fragmented refund tracking call for a separate assessment of orchestration responsibilities. More layers are not automatically better: they introduce rule administration and additional failure points. Base the decision on work your team performs manually today and the operating responsibility it can own, rather than on a product label.
- Which decisions are manual today, and what evidence supports them?
- When a payment remains pending, where does the team start and who owns the investigation?
- What changes in order and finance workflows when a provider is added?
7. Test migration against existing payments before new connectivity
Inventory existing references, open payments, refund flows and record exports. Do not assume stored payment credentials are portable; confirm token scope and required permissions with the relevant provider. Test success, definitive decline, timeout, delayed notification and duplicate notification against a controlled test order. Decide who tracks open attempts during rollback. Shadow evaluation should compare decisions only; it must not initiate two separate charges for the same live order.
- Who owns queries, refunds and reconciliation for payments left in the old system?
- Which acceptance condition stops the migration and triggers a rule or connection rollback?
- Can operations trace a sample payment from the order through to the finance record?
8. Evaluate MagicGate within this framework
MagicGate, MagicPay's B2B technology infrastructure, includes both provider connectivity and payment orchestration. The general distinction in this guide therefore does not limit MagicGate to connectivity alone. For your project, clarify the connections, routing and retry conditions, status queries and operational records using a concrete order journey. Separately establish the role of the authorised institution handling funds, the accounts and the agreements; the technology layer should not be treated as a replacement for that role.