Integration Architecture

[!WARNING] Platform & Global Clearing Access This recipe utilizes Global Clearing logic. Access to the pass-through clearing rails is completely restricted and requires extensive enhanced due diligence (EDD) and a strict reliance model agreement with Verto Compliance. Standard Atlas Platform users cannot perform nested global clearing without special provisioning.

Use this flow when your platform must collect funds into a downstream customer context and later send those funds onward through a nested Global Clearing payout.

✅ Before you start

Complete these steps before you implement this flow:

Confirm your account is approved for Global Clearing and nested third-party payout activity.
Authenticate with your master platform credentials.
Prepare to create and track a sub-account for the downstream customer.
Register webhook endpoints so you can detect inbound credits and payout state changes.
Gather the sender and recipient details required for the final payout.

📚 Use this page with the recipe

This guide explains when to use the Global Collection to Payout flow and the minimum sequence. For the implementation walkthrough, use the recipe:

Global Collection to Payout Recipe →

sequenceDiagram
    participant P as Your Platform
    participant V as Verto API
    participant C as Sub-Account (End-User)
    participant B as External Beneficiary

    P->>V: 1. Create Sub-Account (POST /sub-accounts)
    V-->>P: sub_acc_id_998
    P->>V: 2. Add KYC/KYB Data (POST /onboarding-data)
    V-->>P: Verification: PENDING
    P->>V: 3. Issue vIBAN (POST /accounts)
    V-->>P: IBAN: GB29VERT...
    C->>V: 4. Inbound Payment (Local Rail)
    V-->>P: Webhook: iban_to_wallet (5000 GBP)
    P->>V: 5. Execute Payout (POST /send)
    V-->>B: Funds Dispatched

The Global Collection to Payout workflow

This use case follows a strict sequence:

Create the sub-account that will own the collection and payout context.
Complete onboarding and wait for approval before the customer can transact.
Issue collection details in that same sub-account context.
Wait for the inbound collection event and confirm the funds have arrived.
Send the payout from the same customer context with the required ultimate_sender data.

What makes this use case different?

Unlike standard receive or payout flows, this model is specifically for programs that need to:

collect funds into a downstream customer context
keep collection and payout activity tied to the same sub-account
satisfy nested Global Clearing requirements
include ultimate_sender data in the final outbound payment

Where to go deeper

Use the product guides when you need implementation detail for a specific step:

🎯 Success Indicators

Event	Webhook Signature	Action
Collection	`iban_to_wallet`	Notify your UI that the user's balance has increased.
Payout	`wallet_to_account`	Confirm to the sub-account that the transfer is in progress or completed.

Troubleshooting

Issue	What to check
Sub-account cannot receive or pay out	Confirm onboarding is complete and the sub-account is operationally approved for this flow.
Inbound funds arrive but payout should not start	Wait for the receive webhook status to reach `completed` before releasing funds downstream.
Payout is rejected immediately	Check that `ultimate_sender` is present and that the recipient and corridor are approved for Global Clearing.
Wrong customer context is debited	Verify the `X-Sub-Account-Id` header and the source wallet belong to the intended sub-account.

Next steps


Retry a Timed-Out Payout Safely → Handle uncertain payout outcomes safely with idempotency and webhook reconciliation.	End-to-End Payment Flow → Return to the simpler direct own-funds payout pattern.