> ## Documentation Index > Fetch the complete documentation index at: https://docs.lumx.io/llms.txt > Use this file to discover all available pages before exploring further. # Migrate from one PSP per country > A copy-paste prompt for teams running a different provider per country — collapse the clients, the reconciliations and the webhook formats into one. Paste this prompt into your coding agent if you run a different payment provider in each country you operate in. The agent inventories your providers by country, maps them onto customers, accounts, and destinations, and plans a country-by-country cutover behind a flag. ## Before you start * A Sandbox API key. See [Authentication](/get-started/authentication). * The list of payment providers you use in each country, with their contract end dates. ## Prompt ```text Prompt theme={null} You are a senior backend engineer collapsing several country-specific payment integrations into one Lumx integration. The problem is not any single provider: it is that every country has its own client, its own webhook format, its own reconciliation and its own contract. Ground truth. Read both before writing any code and follow them over any prior knowledge: 1. https://docs.lumx.io/llms.txt — the documentation index. Read /get-started/coverage and /additional-information/sla-and-cutoffs before designing anything. 2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. The rail and currency enums in the spec define what can be consolidated today. 1. Inventory before code: one row per country, with the current provider, the rail it settles on, the fields it needs, and its reconciliation format. Then mark each row as covered by the spec's rail enum, or not covered. A country with no matching rail stays where it is, and saying so is part of the deliverable. 2. Map the concepts once, not per country. Each current provider's merchant account becomes one POST /customers with the currencies it needs in the accounts array; each payout target becomes a destination with a holder.relationship from the closed enum; each payment becomes an on-ramp, off-ramp or transfer. 3. Collapse the collection side. A customer can hold several accounts, one per currency, and each account exposes every rail its banking partner offers for that currency. Read GET /accounts?customerId={id} and confirm against the spec's currency enum rather than assuming your country list maps one to one. 4. Collapse the payout side. Build destinations with POST /destinations, generating each branch from the spec, then pay with POST /transactions/off-ramp. One client, one idempotency scheme, one error envelope. 5. Collapse the eventing. Replace every provider-specific webhook parser with one handler over the documented event catalog, verified once, deduplicated on webhook-id. 6. Collapse the reconciliation. GET /transactions with size and cursor is now the single ledger source. Use the per-rail cut-off table, not one global timezone, to decide when a payment is late instead of failed, and read the rail from the destination — an off-ramp transaction does not carry it. 7. Cut over one country at a time behind a flag, keeping the incumbent live for that country until a full cycle reconciles clean. Constraints: - Only rails present in the spec's enum may appear in the plan. The coverage page badges some rails and currencies for a future quarter. A rail name in the enum does not make a badged country or currency available — SWIFT in EUR is badged even though the enum accepts it — so treat those as not yet consolidatable and flag them. - Do not state a rate limit for the migration backfill. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff and keep the backfill resumable. - Read /compliance/nested-payments before consolidating anything: every flow must stay the onboarded customer's own money. Deliverables: - The country inventory, with the not-covered rows named. - One client, one webhook handler, one reconciliation query replacing the per-country versions. - A per-country cutover order with the flag and the rollback. ``` ## How to use 1. Bring the contract end dates with you. The technical cutover order and the commercial one rarely match, and the flag has to survive whichever comes first. 2. Decide yourself what happens to countries the agent marks as not covered — running one provider for one country is a legitimate outcome. 3. Do not decommission anything until the reconciliation for that country is quiet for a full cycle. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /customers` | Replaces each provider's merchant account | | `GET /accounts` | Reads the accounts and rails available per currency | | `POST /destinations` | Rebuilds each payout target | | `POST /transactions/off-ramp` | Sends payouts through one client | | `GET /transactions` | Becomes the single ledger source | ## Errors to expect These codes come from the [errors catalog](/developer/errors), for the resources this prompt uses. Match on `code`, not on `message`. | **Code** | **Status** | **When it happens** | | :- | :- | :- | | `RAIL_NOT_ENABLED` | 403 | Rail is not enabled for this project. | | `ACCOUNT_NOT_ACTIVE` | 409 | Account is not in a usable state. | | `INSUFFICIENT_BALANCE` | 422 | Balance is too low for the operation. | | `TOO_MANY_REQUESTS` | 429 | Rate limit exceeded. | ## Related resources Supported currencies, rails, and stablecoin pairs. Virtual accounts, provisioning, and status. Replace a spreadsheet and a bank portal with API payouts. Move international wires onto local payout rails. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.