Nuvion supports three ways to accept payments from your users: directly into provisioned account details shared with the payer, a hosted bank transfer checkout that handles the full authentication flow, and a direct card payment API for platforms that want to collect card details themselves.Documentation Index
Fetch the complete documentation index at: https://docs.nuvion.co/llms.txt
Use this file to discover all available pages before exploring further.
Accept via account details
Entities can receive funds directly into their Nuvion account using provisioned banking coordinates — no hosted checkout or payment session required. Share the account details with your payer and Nuvion notifies you via webhook when funds arrive.How it works
- Provision account details for the entity (
POST /account-details,asset_type: fiatorstablecoin). - Share the returned banking coordinates — account number, sort code or routing number, BIC/SWIFT — with the payer.
- The payer initiates a bank transfer from their own bank to those coordinates.
- Nuvion credits the entity’s account and fires
inflows.completed.
Webhook: inflows.completed
Listen for inflows.completed to be notified when funds arrive. This is the authoritative signal that the account has been credited.
Unique identifier for the inflow transaction.
Amount received in the smallest currency unit. e.g.
10000 = $100.00 USD.ISO 4217 currency code of the received funds.
Idempotency reference for the transaction. Use this to deduplicate webhook deliveries.
Identifier for the sender’s account.
The ID of the Nuvion account that was credited.
The ID of the entity whose account was credited.
Always
successful for this event.Payment reference provided by the sender.
Fee applied to the inflow in the smallest currency unit.
Always
inflow.Open Banking
Nuvion hosts the bank transfer checkout page. Your server creates a funding session, redirects the user to the hosted URL, and receives a webhook when funds settle. Supported currencies:GBP, EUR
Create a funding session
Amount in the smallest currency unit.
10000 = £100.00 GBP. Minimum: 1.ISO 4217 currency code. One of
GBP, EUR.The ID of the account to credit when the payment settles.
HTTPS URL to redirect the user to after they complete or abandon the checkout. Must use HTTPS.
A unique idempotency key for this session. 1–255 characters. Submitting a duplicate reference returns a
409 with the original session’s payment_id.Display text shown to the user on the checkout page. Max 255 characters.
ISO 3166-1 alpha-2 country code of the payer. e.g.
GB, DE. Used to tailor the checkout experience to the payer’s country.Optional key-value metadata to attach to the session.
Redirect the user
Redirect your user to thecheckout_url returned in the response. Nuvion handles bank authentication, authorisation, and error states on the hosted page.
Handle the return
When the user completes or abandons the checkout, they are redirected to yourredirect_url. Do not treat the redirect as confirmation of payment — always verify status via webhook or API.
Check session status
Funding session statuses
| Status | Terminal | Description |
|---|---|---|
awaiting_user | No | Session created, user has not started |
processing | No | User has initiated the bank transfer |
pending_settlement | No | Transfer accepted by the bank, awaiting settlement |
settled | Yes | Funds credited to the account |
failed | Yes | Transfer rejected by the bank |
expired | Yes | Session expired before the user completed payment |
cancelled | Yes | Session was cancelled |
failed, the response includes a failure_code:
| Code | Retryable | Reason |
|---|---|---|
insufficient_funds | Yes | Payer account has insufficient funds |
bank_rejected | Yes | Bank rejected the transfer |
account_closed | No | Payer account is closed |
authorization_revoked | No | Authorisation was revoked |
provider_error | Yes | Internal provider error |
Webhook
Listen forfunding_session.updated to receive real-time status changes. Nuvion retries webhook delivery for 72 hours with exponential backoff.
Accept via card
Nuvion’s card payment flow uses a Payment Intent and an Intent Action. Create a Payment Intent to declare the charge, then submit an Intent Action to confirm the payment.Step 1: Create a payment intent
A Payment Intent represents your intent to charge a card. No funds are moved at this stage.ISO 4217 currency code. e.g.
USD.Amount in the smallest currency unit.
5000 = $50.00 USD.The ID of the account to credit on successful charge.
Your unique internal order or transaction reference.
A human-readable payment description. Maximum 250 characters.
Optional confirmation details. Include this when you want to create the Payment Intent and submit the card payment in the same request.
status: requires_action. No charge happens until you submit an Intent Action.
Create and confirm in one request
If your server already has the encrypted card payload, you can includeintent_action when creating the Payment Intent.
Step 2: Submit an intent action
Submit the card payment usingPOST /intent-actions with payment_type set to card-acq and the encrypted card payload in payment_type_data.data. See Card data encryption for how to create this value.
The ID of the Payment Intent to charge against. The intent must still have
status: requires_action.Always
confirm.Always
collections.The payment method. Use
card-acq for card payments.Base64-encoded RSA-OAEP SHA-256 encrypted card object.
Cardholder billing address.
Card authentication model. One of
3ds_required or 3ds_disabled. Defaults to 3ds_required.Browser data used for 3DS authentication. Required unless
auth_model is 3ds_disabled.Cardholder identity details.
URL to redirect the cardholder to after 3DS completes. Required unless
auth_model is 3ds_disabled.Without 3DS
Use this path when the card does not require strong customer authentication.With 3DS
3DS is the default card authentication model. If you omitauth_model, Nuvion treats the payment as 3ds_required, and browser_info becomes required. If the issuer requires customer interaction, the response returns status: pending_user_action, requires_action: true, and a next_action.url to redirect the cardholder to.
next_action.url. After authentication, Nuvion redirects the cardholder to return_url. Do not treat the redirect as proof of payment; confirm completion from the payment intent status or webhook.
Step 3: Check payment status
UseGET /payment-intents/{id} to check the latest status after redirect or while waiting for a webhook.
Apple Pay
For Apple Pay, setintent_action.payment_type to applepay-acq. Apple Pay does not use payment_type_data.data, full billing address fields, or card encryption in this request. The only required billing field is payment_type_data.billing_address.country.
Payment intent statuses
| Status | Description |
|---|---|
requires_action | Intent created — no action submitted yet |
processing | Intent action is being processed |
completed | Charge successful |
cancelled | Intent cancelled before completion |
failed | Payment could not be completed — check status_reason |
Intent action statuses
| Status | Description |
|---|---|
pending | Action created and being processed |
pending_user_action | Awaiting 3DS completion from the cardholder |
completed | Charge successful |
failed | Charge declined or failed |
Webhooks
Use Payment Intent webhooks as the final confirmation that a card payment succeeded, failed, or was cancelled. This is especially important after a 3DS redirect, because the redirect only tells you the customer returned to your site.| Event | Trigger |
|---|---|
payment_intent.completed | Charge successful — funds credited to the account |
payment_intent.failed | Charge declined or failed |
payment_intent.cancelled | Payment Intent cancelled before confirmation |
2xx response after receiving the webhook. If delivery fails, Nuvion retries with exponential backoff. See Webhooks for delivery and retry details.
What’s next
Send a payout
Send funds from an account to any bank account globally.
Stablecoins
Accept USDC and USDT via a provisioned wallet address.
Payment Intents API reference
Full endpoint documentation for payment intents and intent actions.
