Design and development

The sandbox is ChatterPay B2B's first technical reference Partner. It must not have shortcuts into the API's internals: its purpose is to exercise the same public contract and the same boundaries a later external Partner will use.

The journey is:

Browser
→ Partner Sandbox BFF
→ B2B SDK
→ B2B API
→ Recipient Resolver
→ Operation / Workers
→ Partner Signer Gateway
→ Chain Adapter
→ test network or simulator
→ reconciliation and events
→ signed webhook to the Partner Sandbox BFF

The sandbox creates users and wallets via the SDK, registers and resolves aliases via the public API, obtains quotes, creates operations and receives its own signed webhooks.

On Anvil and EVM testnets it also exercises the Partner Signer Gateway, including per-wallet EIP-7702 authority via keyReference. The API does not receive the master key.

In Mock the same service boundary is preserved even though blockchain execution is simulated: EVM and Bitcoin transfers, and simulated LI.FI executions, pass a synthetic digest per operation through the Partner Signer Gateway, so the sandbox does not skip the signing boundary. Bitcoin Mock also obtains from the gateway the public key used to derive its P2WPKH address.

The Reference Partner application continues to exist as a second, independent consumer for conformance testing. No real-funds deployment is implied by this description.

Components are connected through versioned contracts:

• OpenAPI for HTTP;
• event schemas;
• the published SDK;
• ABIs and manifests for contracts;
• images identified by digest;
• a per-release compatibility matrix.

API changes must validate compatibility, regenerate the SDK, compile examples, update the documentation and pass end-to-end tests.

The reference application and the sandbox consume public surfaces the same way a real Partner would.