Build stablecoin accounts into your product
Product / Finance API
Virtual accounts, stablecoin accounts, payouts and stablecoin transfers: one API for all four.
Venly coordinates the partner setup each flow needs.
Talk to us
View API reference
The problem
Four vendors for one financial product
4 contracts
Separate vendor agreements for accounts, wallets, IBANs, and KYC.
4 timelines
Each integration has its own API, sandbox and go-live schedule.
4 reviews
Separate compliance reviews for each vendor, which multiplies legal overhead.
The account model
A clear, composable architecture
Parties are identities. Accounts are containers. Wallets hold stablecoins, receiving accounts take in USD or EUR, and payment sessions and transfers move money. Each layer builds on the last.
Party
Identity layer
Individual
→ KYC verification
Organisation
→ KYB verification
Account
Container
Wallet
Stablecoins on the chains enabled for your account
Receiving account
USD or EUR in; supported stablecoins out
Transfers
Payment sessions & crypto transfers
Six capabilities in one API
Each row is one object in the API, the part it plays in Maria’s account, and the guide that documents it.
Object
In Maria’s account
Details
Guide
Party management
Party
Create and manage individuals and organisations with built-in identity verification.
Maria is an individual party. Her verification starts at VERIFICATION_PENDING.
- Individuals: first name, last name, address → KYC verification
- Organisations: name, VAT number → KYB verification
- Verification status: VERIFICATION_PENDING, VERIFIED or REJECTED
- External ID mapping to your own user database
Account management
Account
Create accounts that hold wallets, receiving accounts and payment instruments.
Maria’s account carries your own ID for her: user-123.
- Create an account with an existing or new party and the configured wallet model
- Role-based party associations (ACCOUNT_HOLDER)
- Multiple parties per account, multiple accounts per party
- Account lifecycle and status tracking
Crypto wallets
Wallet
Provision or connect wallets according to your account's custody model.
Her USDC balance, on Base.
- Managed wallets can be provisioned when the account is created
- Chain and asset availability depend on account configuration
- Real-time balance queries
- Primary asset: USDC
Receiving accounts (virtual IBANs)
Receiving account
Give customers USD or EUR receiving details. Incoming funds convert into the configured stablecoin.
Her USD receiving details, reached by ACH transfer.
- USD through enabled account instructions; EUR through SEPA
- Receiving details vary by bank rail
- Fiat converts into the configured supported stablecoin
- GBP payouts by Faster Payments are supported; GBP receiving details are being added
Fiat-to-crypto payment sessions
Payment session
Create a hosted bank-payment session for an enabled pay-in flow.
Not used in Maria’s story: her money arrives by ACH transfer.
- Specify the amount, currency and target stablecoin
- Return a hosted paymentUrl for the customer
- EUR open banking requires an active compatible EUR receiving account; follow status through callbacks
Crypto transfers
Transfer
Transfer supported stablecoins between eligible accounts on your platform.
50 USDC from Maria to Carlos, PENDING and then COMPLETED.
- POST /accounts/{senderAccountId}/transfers/crypto
- Enabled chain and asset configuration applies
- Track PENDING, COMPLETED or FAILED outcomes
- Idempotent through the idempotencyKey body field
The account lifecycle
Follow Maria’s account from sign-up to transfer.
Each step shows Maria’s screen in your app beside the view your team works from. The story follows one USD receiving account that converts to USDC.
Create
Create the customer account
Creates the account and its party association. Verification and partner requirements have their own status.
Receive details
Request USD receiving details
Maria gets USD receiving details through enabled account instructions, subject to account and partner requirements. EUR works through SEPA.
USD and EUR receiving details on Virtual accounts
Receiving in EUR? The EUR virtual IBAN to USDC
Payment in
A USD payment arrives and converts
An ACH transfer reaches Maria’s receiving details. The incoming USD converts into USDC, the stablecoin configured for this account. Follow the payment and conversion status.
Hold
Balances stay in supported stablecoins
Maria’s balance is held in USDC, the primary asset, on the chain enabled for her account. Your team queries the same balance through the API.
Transfer
Request a transfer
Maria sends 50 USDC to Carlos, another eligible account on your platform. The request is idempotent through its idempotencyKey.
Safe retries with idempotency keys
Transfer
Follow the status to its outcome
A transfer reports PENDING, COMPLETED or FAILED. Your app can show Maria the same outcome your team reads from the API.
These operations show the account flow. Complete verification, partner setup and funding separately; available assets and routes depend on configuration.
The requests, fields and statuses in this story are documented in the API reference.
The integration walkthrough, step by step
Platforms build accounts like Maria’s into financial products, payroll and marketplaces.
Beyond one flow
Who builds with these accounts
Financial products
How a neobank launches these accounts, release by release
Payroll platforms
Paying recipients in other countries
Marketplaces
Seller payouts to a bank or a wallet
Your company’s own balances run on a different product.
Converting your company’s own balances with Fundflow
Add money
Money in
Multiple on-ramp methods
Available by setup
Being added
Bank transfer
Customers send USD or EUR using their enabled receiving instructions. Incoming funds convert into the configured stablecoin.
Best for: Large amounts, recurring deposits, business users.
Open banking (payment sessions)
For an enabled EUR flow, generate a hosted bank-payment session. The customer authorizes the payment through their bank; follow the payment and conversion status.
Best for: Customers who prefer to authorize a bank payment inside a hosted flow.
Card and digital wallets
Let end users buy stablecoins with a card, Apple Pay or Google Pay inside your app. Being added; ask Venly for availability.
Best for: Consumer users, micro-deposits.
For your developers
Built for production
Maria’s transfer to Carlos from the story above, as your backend sends it.
Transfer request
The request is idempotent through its idempotencyKey.
- REST API with OpenAPI spec
- OAuth2 client credentials authentication
- Idempotent POST requests (idempotencyKey body field)
- Optimistic locking on updates (version-based concurrency)
- Paginated list endpoints with filtering & sorting
- Real-time callbacks on pay-in sessions (callbackUrl)
- Webhooks to one registered HTTPS endpoint for pay-ins, transfers, pay-outs, verification verdicts and virtual bank accounts
- External ID mapping for supported resources
- Two environments: the sandbox and production
- Comprehensive error codes
- Idempotent, audit-logged API
SDK, React components and MCP tools
Questions about the Finance API
Which currencies can customers receive?
USD through enabled account instructions and EUR through SEPA. Incoming funds convert into the configured supported stablecoin.
Which stablecoin do accounts hold?
USDC is the primary asset. Chain and asset availability depend on your account configuration.
What statuses does a transfer report?
PENDING, COMPLETED or FAILED. Transfer requests are idempotent through the idempotencyKey body field.
How does the API authenticate?
With OAuth2 client credentials. There are two environments, the sandbox and production.
Build your financial product
Start with the documentation and scope your account, verification and payment requirements with us.
Talk to us
Read the documentation
Learn the concepts
All insights
Learn the concepts
Virtual IBAN, explained
How named virtual accounts work as a settlement primitive for platforms.
Multi-rail settlement
How each payout is routed over the rail it needs.
Who can mark Maria as verified
Opening an account is not completed onboarding. The account starts at kycStatus VERIFICATION_PENDING, and your platform cannot set it to VERIFIED. Verification and partner requirements have their own status.
SOC 2 Type 2 certified. Our own licences are in flight and flows run on licensed partner rails today.