customerId from the application.approved webhook — see Onboard a Customer and The Onboarding Lifecycle. Calling features before the customer is active returns CUSTOMER_NOT_ONBOARDED.
Test this flow in sandbox. Drive it end-to-end with simulated money and deterministic controls — start with the sandbox quickstart, then deposit simulation for this flow, and the cheat sheet for every magic value and simulate endpoint.
Flow
Add Virtual Accounts by submitting a feature application against an existing customer. The integration:- Discover the customer’s feature requirements.
- Submit a
virtual_accountfeature application. - Listen for
application.approvedorapplication.rejectedwebhooks (withapplicationType: "virtual_account"). - Listen for
virtual_account.activated. - Fetch the customer’s Virtual Accounts and read
balances[]plusdepositInstructions[].
Request The Feature
Discover any extra requirements for the customer:fields and documents. When present, collect them and include them in the submit body below. When the response asks for nothing extra, submit with just type and asset.
Submit the Virtual Account feature application for the target asset. Idempotency-Key is required — without it the call returns IDEMPOTENCY_KEY_REQUIRED.
202 Accepted with a Virtual Account feature application carrying its own application id. Track it through the application.approved and application.rejected webhooks with applicationType: "virtual_account". A rejection carries resubmittable: when it is true, correct the data and request the feature again; when it is false, the decision is final.
Listen For Activation
Once the feature application is approved, listen forvirtual_account.activated to know the Virtual Account is usable. Deposit instructions populate once the Virtual Account’s status is active. See Webhooks and Virtual Accounts.
Retrieve Deposit Instructions
After activation, fetch the Virtual Accounts for the customer. See Virtual Accounts for the full deposit-block union.sepa block on the same endpoint. Send to the iban and the bic: