Payload API v2 represents a shift in how we think about what an embedded payments API should expose. Platforms get primitives they can compose, not workflows they have to conform to. Four capabilities show this most clearly: native synthetic accounts, multi-party splits in a single call, instant payouts via RTP, and fully embedded onboarding.

Each one is a deliberate architectural choice. Together, they share a through-line. That through-line is what v2 is really about.

Here's the design thinking behind each.

Subledger accounts inside Payload. No external rails involved.

Most embedded finance use cases (wallets, escrow, store credit, prefunded payout balances) have historically required platforms to either build their own ledger or stitch together multiple vendors. v2 introduces synthetic accounts as a first-class primitive, created under the same unified /accounts endpoint as any other account type. They start at $0, fund via credit transactions from any source, and update balance in real time as transactions clear.

Internal transfers between synthetic accounts don't route through ACH or any other external rail. They settle inside Payload. That matters less for the transfer speed than for what it enables: real ledger semantics for product features that need them, without the regulatory and operational overhead of being a bank.

This is the primitive that the rest of v2's most differentiated features depend on.

A new transfers array on payment transactions. One API call, atomic settlement, multiple destinations.

Marketplaces, franchise platforms, IOLTA trust workflows, revenue-sharing models: the pattern is the same in each. A single inbound payment needs to land in multiple places at once. Vendor, platform fee, royalty, sub-merchant. V1 customers built this with multiple sequential transactions and reconciled the splits themselves. The new approach uses one transaction object, a transfers array describing each destination and amount, and atomic execution.

The architecture also supports reverse flows: debits from multiple processing accounts consolidating into a single deposit. Commission aggregation, consolidated payouts, multi-account collection — same primitive, inverted. Each transfer in the array generates a corresponding Transfer object for tracking and reconciliation, which means the splits are first-class records, not derived state.

Atomicity is the part that matters most. Partial splits don't happen. The full transaction either lands or doesn't, which is the only behavior that makes sense when the splits represent real money owed to real counterparties.

Real-time disbursement on the RTP network, funded from synthetic accounts. Funds reach recipient bank accounts within seconds.

The mechanism is exactly what it sounds like: set clearing_timing='instant' on a payout transaction, source it from a synthetic account balance, and Payload routes it via RTP. The one-time delay is funding the synthetic account in the first place; that initial deposit clears overnight. After that, every payout drawn from the synthetic balance is instant.

The architectural detail that matters: automatic fallback. RTP coverage is not universal. When a recipient's bank doesn't support RTP, Payload falls back to ACH or wire automatically and returns the routing decision in the API response. Platforms don't write the fallback logic. They don't even decide rail-by-rail. The system handles it and tells you what it did.

This is what "built for real-world workflows" actually means. The clean version of instant payouts ("every recipient gets funds in seconds") isn't real. The actual version, where coverage varies and degradation has to be graceful, is what shipped.

KYC, KYB, and processing account enrollment, fully API-driven. No redirects, no hosted forms required.

V1 customers had two enrollment options, both involving a Payload-rendered interface: the Enrollment Link and the Enrollment Plugin. Both still exist in V2 for platforms that prefer them. What's new is the third option: full backend control. Submit entity data, bank account details, and beneficial ownership information directly via API, in one call. The Processing Account and Entity objects are created or updated together. KYC verification triggers automatically based on the submitted data.

The entity system itself was rebuilt to support this. Individual and business entities, attachment to any account type, international identities with country-specific tax IDs. Platforms that want a white-label onboarding flow (especially mobile-native platforms where a hosted redirect breaks the experience) can now build it without compromise.

The decision underneath this feature: platforms shouldn't have to choose between control and convenience. Both flows are first-class. You pick the one that fits the experience you're building.

Synthetic accounts are a primitive. The transfers array is a primitive. Instant payouts is a workflow built on synthetic accounts. API-driven enrollment is the same principle applied to the onboarding layer: give platforms the surface to build, not just the form to fill out.

v2 marks a shift in how we think about what an embedded payments API should expose. The four capabilities we announced are where that shift is most visible. Everything else in the release follows the same logic.

The complete v2 reference is at docs.payload.com/v2. The What's New page lists every net-new capability with no v1 equivalent.