Channels, authorization and execution models

They are different entry channels that converge on the same B2B Core.

In Partner-app-first, the user operates from the Partner's app; the Partner authenticates, presents the quote and obtains confirmation before calling the SDK/API.

In WhatsApp-first, the user starts from the Partner's number/WABA and a conversational instance scoped to that tenant gathers the intent, resolves the recipient, presents the quote and records the confirmation. WhatsApp does not run its own financial logic and does not replace the ledger, the signer or the reconciler.

Not necessarily. The architecture supports several authorization policies: direct user confirmation inside the channel for enabled operations; synchronous callback to the Partner's backend; previously signed grants/assertions; or step-up in the Partner's app. The tenant can combine these policies by amount, risk, destination or capability.

The lowest-complexity initial option is direct confirmation in WhatsApp for a previously linked user, with limits, idempotency, tenant policy and signing policy. Higher-risk operations can escalate to an additional Partner approval.

No. The channel still belongs to the B2B context as long as the user is linked to the Partner's tenant, the number/WABA and configuration belong to the Partner, the policies and limits are the tenant's, and signing for a real deployment runs in infrastructure controlled by the Partner.

The architecture contemplates three models:

1. ChatterPay coordinates execution: the Partner or channel hands over an authorized intent; ChatterPay creates the Operation, builds the payload, requests a signature from the Partner's signer, submits, observes and reconciles.
2. The Partner executes on-chain on its own: ChatterPay can resolve recipients and, if the result is integrated, observe and reconcile a transaction the Partner built, signed and submitted externally.
3. ChatterPay builds and the Partner submits: ChatterPay returns a payload/digest tied to the intent and the Partner keeps signing and broadcast; it must later import the result to close the Operation.

The initial model is for ChatterPay to coordinate the full lifecycle while the Partner keeps cryptographic control through its Partner Signer Gateway. It reduces additional contracts, keeps idempotency and reconciliation inside a single Operation, and lets app and WhatsApp share the same flow.

ChatterPay stops controlling part of the lifecycle. To keep equivalent tracking, ledger and webhooks, the Partner must link the external transaction to an Operation via an identifier and a tx_hash or equivalent reference. Without that link, ChatterPay can observe the blockchain but cannot safely attribute the movement to a specific commercial intent.

No. The main pattern is webhook to update + GET Operation/events to recover. The Partner can keep its own UI and feed it with status, network, asset, amount, fees, on-chain references, timestamps and errors published by the API.

A white-label user portal, a Chatizalo operational dashboard, or a B2B administration console are additional, separate surfaces; they are not required for the main integration to work.