> ## Documentation Index > Fetch the complete documentation index at: https://docs.zeam.money/llms.txt > Use this file to discover all available pages before exploring further. # Provider on-ramps > Set up bespoke connectors so your customers can pay in through a provider, for example with an EasyPay number. Most connectors are quoted and then initiated. Bespoke connectors work the other way round: the customer pays the provider first, and the payment pays out to one of your wallets. You don't quote or initiate these payments. Instead you set the customer up once: 1. Register the customer with the connector's provider, if the provider requires it. 2. Register an on-ramp reference for the customer, bound to one of your wallets. 3. Give the customer what they pay against. Every payment on it pays out to that wallet. All examples assume the two headers every protected request sends, as in [Your first transaction](/guides/your-first-transaction): ```http theme={"theme":{"light":"github-light","dark":"one-dark-pro"}} Authorization: Bearer YOUR_ACCESS_TOKEN x-zeam-auth: YOUR_APP_SECRET ``` List connectors with `flow=BESPOKE`. Every filter is optional; add `countryIsoCode2`, `method`, or `direction` to narrow the list. ```bash cURL theme={"theme":{"light":"github-light","dark":"one-dark-pro"}} curl -sS "https://api.zeam.money/gw/v1/connectors?countryIsoCode2=ZA&direction=ON_RAMP&flow=BESPOKE" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "x-zeam-auth: YOUR_APP_SECRET" ``` Each connector in the response carries `flow`. Keep the `id` of the one you want; the next steps call it `connectorId`. Responses from the reference endpoints return the same id as `routeId`. Some providers, for example Noah, verify the customer themselves before they accept payments, and refuse a reference for a customer they don't know. EasyPay doesn't, so skip this step for EasyPay. `customerId` is your own id for the customer. It only needs to be unique within your association. Only `returnUrl` is required, and it must be an `https` URL; any other fields you send prefill the provider's onboarding. ```bash cURL theme={"theme":{"light":"github-light","dark":"one-dark-pro"}} curl -sS -X PUT https://api.zeam.money/gw/v1/customers/cust-1001/connectors/CONNECTOR_ID/register/individual \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "x-zeam-auth: YOUR_APP_SECRET" \ -H "Content-Type: application/json" \ -d '{ "returnUrl": "https://your-app.example/onboarding/done" }' ``` The `status` in the response tells you what to do next: | Status | Meaning | | - | - | | `Pending` with a `hostedUrl` | Send the customer to `hostedUrl` to complete verification. | | `Pending` (`202`) | The provider is reviewing the customer. | | `ActionRequired` | Something needs the customer's attention; send them to `hostedUrl`. | | `Verified` (`201`) | The customer can pay in. | | `Rejected` | The provider declined the customer. | Registering the same `customerId` again returns its current status. To be told when the provider decides, [subscribe](/webhooks/create) to `Customer_Verified` and `Customer_Rejected`. Use `register/business` for a business customer; it also requires a two-letter `registrationCountry`. Bind a reference to one of your wallets. `settlementAccount` is the wallet's Stellar public key, from `GET /v1/wallets`, and the wallet needs a trustline for the connector's settlement asset. ```bash cURL theme={"theme":{"light":"github-light","dark":"one-dark-pro"}} curl -sS -X POST https://api.zeam.money/gw/v1/onramp/references \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "x-zeam-auth: YOUR_APP_SECRET" \ -H "Content-Type: application/json" \ -d '{ "connectorId": "CONNECTOR_ID", "settlementAccount": "GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN", "customerId": "cust-1001" }' ``` What the customer pays against depends on the provider. For EasyPay it is the `reference` itself, the EasyPay number. For Noah it is the payment details in `metadata`, for example the bank account to transfer to. Providers that issue more than one reference per customer return the rest in `relatedReferences`, each with its own `reference` and `metadata`. | Status | Cause | | - | - | | `404` | The settlement account isn't one of your wallets (including a malformed key), the connector is unknown, or the provider requires the customer to be registered first and they aren't. | | `409` | The customer already has references on this connector (list them with `GET /v1/onramp/references?customerId=cust-1001` instead), or the provider's references couldn't be assigned. | | `422` | The wallet has no trustline for the settlement asset, or the connector doesn't issue references. | Payments on a reference are not submitted by you, so they have no transaction record. Follow them with [webhooks](/webhooks/events): each payment raises the usual `Intent*` events, and on its lifecycle events `metaData.data` carries the payout summary (`netAmount`, `totalFees`, `assetCode`) and the `onrampReference` it arrived on. Once settled, the payout also shows in the wallet's balance and statement. ## Move references to another wallet Rebinding changes where future payments land. The new settlement account must also be one of your wallets, with a trustline for the settlement asset. * Move every reference a customer has on a connector: `PUT /v1/onramp/references` with `connectorId`, `customerId` and `settlementAccount`. * Move a single reference: `PUT /v1/onramp/references/{reference}` with `settlementAccount`. ## List references `GET /v1/onramp/references` filters by `customerId`, `settlementAccount`, and `connectorId`. Unlike the other collections, it pages with `pageNumber` and `pageSize` (up to 100) and returns `{data, pageNumber, pageSize, count}`, where `count` is the total number of matches. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.