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.

Because the API, SDK, contracts, documentation, infrastructure and reference application have different responsibilities, permissions and publication cycles.

The separation forces the integration to work through public contracts and prevents hidden dependencies between internal implementations.

Coordinated changes are validated through releases and cross-repository tests.

SDD, Spec-Driven Development, means that behavior, contracts, states, events, constraints and acceptance criteria are defined before the code is changed.

Machine-readable contracts (structured files tools can read and validate automatically) let you verify that the API, SDK, events, documentation and tests express the same decision.

Agents can analyze impact, propose changes, work on isolated branches, run checks and prepare evidence.

The specification remains the source of truth and final integration requires automated gates and human review.

The goal is not to delegate ambiguous decisions to a model, but to turn previously defined decisions into traceable, verifiable changes.

It must prove, as applicable:

• domain rules;
• idempotency;
• tenant isolation;
• PostgreSQL transactions;
• contracts and storage;
• signatures;
• replay and nonces;
• adapters and providers;
• failures and timeouts;
• retries;
• ambiguous broadcast;
• observation and reorgs;
• ledger and reconciliation;
• webhooks;
• upgrades and rollback;
• security;
• restoration;
• an end-to-end journey from a public surface.

The existence of code or a deployed contract does not imply the capability is enabled to operate with real funds.