Skip to main content
Use a quoted pay-in when the customer needs to fund a specific amount. The transfer settles stablecoin into an issued wallet.

​
Before you start

You need a ready pay-in capability and ready issued destination wallet for the same customer. Complete any open work through Capabilities and tasks, then refetch both resources.

​
1. Create a quote

Create the price with POST /v3/quotes. Send these headers:
Store data.id as QUOTE_ID. Present the returned amounts and fees rather than rebuilding them from the rate.

​
2. Execute the quote

Execute the current quote before expiry with POST /v3/transfers. Use a new key for this intended transfer:
Store transfer data.id as TRANSFER_ID and retain its current state.

​
Add a return URL for card and Apple Pay

For a card or Apple Pay quote, you can include an optional redirectUrl in the same request. After the customer finishes the hosted checkout, the checkout page opens this URL to bring the customer back to your app.
redirectUrl must be an absolute HTTPS URL of at most 2048 characters and must not contain embedded credentials. Sending redirectUrl for a quote that does not support return navigation fails validation instead of being ignored. Arrival at redirectUrl is browser navigation only. It does not confirm that the payment or the transfer completed. Determine completion from the transfer state in step 4 and from webhook events.

​
Pre-select the checkout method for a card quote

For a card quote, you can include an optional checkoutMethod in the same request to choose which funding option the hosted checkout opens on. The current values are card, apple_pay, google_pay, cash_app, sepa, and blik. The list is open and can grow, so tolerate values you do not recognize on transfer reads. The checkout opens on the requested method when it is available for the customer and their device, and the customer can still choose any other method the checkout offers. Omit it to keep the default pre-selection.
checkoutMethod is a preference, not a guarantee. Availability depends on the customer, their device, and the checkout, so requesting a method does not make it available. Here sepa and blik are funding options inside the card checkout, not Swipelux capabilities, rails, or accounts. The pre-selection does not change the quote’s capability, amounts, or fees, and the checkout confirms the final fees. Transfer reads echo the requested value; they do not confirm which method the customer used. Sending checkoutMethod for a quote that is not a card quote fails validation instead of being ignored, and a replay with the same idempotency key must send the same checkoutMethod.

​
3. Retrieve funding instructions

Read GET /v3/transfers/{transferId}/instructions. Render the returned data.instructions variant without assuming its type. These details are transfer-specific. Never reuse one transfer’s bank coordinates, code, hosted URL, amount, reference, or expiry for another pay-in. For bank instructions, when reference.required is true, display the exact reference.value next to the bank coordinates and make it copyable. Show the returned amount and currency from the same instruction set. An issued bank account is different: it provides reusable details for later deposits. See Issue a bank account when that is the intended experience.

​
4. Track settlement

Read GET /v3/transfers/{transferId} after execution and after each event. Drive the customer-facing status from the latest data.state. Use data.stateDetail and data.openTaskIds when the transfer needs another action. Do not mark it complete from an expected schedule. Next, add Webhooks and keep the transfer status synchronized until it reaches an outcome your product handles.