Operations

Operational procedures and walkthroughs

These sequences describe how mature teams run B2B crypto payment infrastructure: lifecycle gates, webhook discipline, reconciliation ownership, review cycles, and escalation routing. They are not customer testimonials, throughput claims, or dashboard screenshots.

Illustrative operational flows on this marketing site describe how teams typically work with B2B payment infrastructure. They are not customer testimonials, not performance guarantees, and not quotes from live merchant data.

Docs · Guides · Playbooks · References · Observability · Incidents · Onboarding

Ownership boundaries. Engineering owns webhook verification, consumers, and deployment configuration. Finance owns recognition rules and period close. Product semantics define external states — your mapping is explicit and versioned.
Escalation routing. Classify issues by signal: delivery failures, signature errors, lifecycle mapping drift, reconciliation exceptions, or treasury controls. Route with payment_id and state history — not ad-hoc wallet access.
Reconciliation responsibility. Detection on the rail does not replace your books. Scheduled reconciliation compares authoritative API or event exports to internal orders — exceptions are reviewed, not assumed away.
Operational review cycles. Merchant access, rail enablement, and sensitive controls follow intake and review — not anonymous self-serve production keys. Changes to scope or rails are deliberate configuration events.
Integration change management. Webhook endpoints, secrets, and lifecycle mappings evolve. Treat secret rotation, schema adjustments, and consumer deploys as coordinated changes with rollback plans.
Monitoring expectations. Track non-2xx webhook responses, signature failure rates, growing exception queues, and stuck Paid states on your side. Operational issues usually appear in logs before finance escalations.

Operational walkthroughs

Step-by-step flows teams use to reason about payments — labeled as example operational flows, not live dashboards.

Payment lifecycle (create → confirmed)

How a single payment object moves through explicit states when your backend creates the payment and your systems consume lifecycle signals.

Example operational flow — state names and timing depend on your enabled rails and policy.

01 · Create (server)
Your backend creates a payment with a stable identifier. The payer receives instructions for the enabled rail — not a browser-held API key.
02 · Pending
The payment exists before on-chain detection. Support and finance should treat Pending as “open,” not as success or failure.
03 · Paid
Funds may be detected while your policy still treats the payment as provisional. This is where teams often confuse detection with finality.
04 · Confirmed
Confirmation semantics for your deployment are met. Entitlements and revenue recognition should align to this gate — not to Paid alone.
05 · Expired (branch)
The payment window ends or configuration marks the attempt terminal. Reconciliation should close the original attempt without silent reuse.

Webhook handling (delivery, verify, apply)

Signed callbacks are asynchronous. Retries are normal; your consumer must verify on raw bytes and write idempotently.

Example operational flow — not a delivery SLA or latency guarantee.

01 · Emit
A lifecycle transition triggers an HTTPS POST with a signed body to your endpoint.
02 · Verify
Your server validates the signature over raw bytes before parsing JSON. Fail closed with 401 on bad signatures.
03 · Persist
Record the event or enqueue safe work before returning 2xx. Returning success before durable writes creates ghost acknowledgements.
04 · Retry
Transient failures and timeouts cause redelivery. Idempotent upserts prevent duplicate shipments, credits, or ledger posts.
05 · Reconcile
Periodic API reads backstop webhook gaps. Finance should not assume webhooks alone are the only source of truth.

Signed pipeline · conceptualSIGNEDVERIFIED

Server-side

Signed processing channel

STATEEventLifecycle transitionSTATE · TRANSITIONMerchant backend → signed event

INGRESSPOSTSigned bodyINGRESS · SIGNEDHTTPS POST · signature over raw bytes

VERIFYVerifyServer-sideVERIFY · RAW BODY · SIGNEDRaw body checked before parse

QUEUEApplyIdempotentQUEUE · RETRY SAFEIdempotent apply · retries expected

Reconciliation (detection ≠ books)

Finance and engineering align external lifecycle states to internal orders, revenue, and exceptions — often on a schedule, not in real time.

Example operational flow — not universal accounting advice.

01 · Export states
Pull authoritative statuses or event logs for the reconciliation window your team defines.
02 · Map rules
Document which external state satisfies which internal gate (for example Paid vs Confirmed for entitlements).
03 · Exception queue
Paid-but-not-confirmed, duplicate webhooks, and late confirmations land in an exception queue — not silent auto-fix.
04 · Close period
Treasury signs off when open payments match policy. Expired and abandoned attempts should have explicit handling.

Merchant review (access and rails)

Production access and rail enablement follow intake, qualification, and technical alignment — not anonymous instant keys.

Example operational flow — timelines are not published on this site.

01 · Intake
Use case, geography, rails intent, and technical contact — without secrets in email.
02 · Qualification
Fit and risk review determine whether the model matches B2B server-to-server operations.
03 · Technical alignment
Lifecycle mapping, webhook verification, and idempotency patterns are agreed before go-live.
04 · Approval
Environment configuration and selected rails are enabled intentionally for your integration.

Withdrawal requests (controls)

Merchants initiate withdrawal requests. Execution follows operational controls — not a promise of universal instant settlement.

Example operational flow — controls vary by deployment.

01 · Initiate
A merchant-initiated request is recorded with amount and destination context per policy.
02 · Review
Operational controls may include limits, holds, or manual review — this is discipline, not hidden friction.
03 · Execute
On-chain or treasury execution follows configuration. Failures should surface as operational states, not silent drops.
04 · Reconcile
Finance maps completed movements to ledger entries separate from payment lifecycle semantics.

Escalation (webhook or integration drift)

When delivery fails or semantics diverge, mature teams route to engineering and finance — not “toggle until it works.”

Example operational flow — not a published support SLA.

01 · Detect
Monitor non-2xx rates, signature failures, and growing exception queues — not only payer complaints.
02 · Triage
Classify: endpoint outage, bad secret rotation, schema drift, or mapping bug in your consumer.
03 · Coordinate
Engineering fixes verification and idempotency; finance pauses automated settlement if needed.
04 · Verify
Replay or backfill from API reads after fix. Document root cause — retries will happen again.

Example merchant workflows

Anonymized, workflow-oriented narratives — no fake names, logos, volumes, or KPIs. Use them to stress-test your integration and finance mapping before production traffic.

saas · billing

SaaS billing (illustrative)

A B2B software team enables paid plans using server-created payments and webhook-driven entitlements.

Example operational flow — not a named customer or measured outcome.

Merchant goal: Convert a subscription checkout into a durable entitlement with finance-visible states.
Integration pattern: Checkout calls your backend; your backend creates payments and stores payment_id on the subscription record. API keys remain server-side.
Lifecycle handling: Provision on Confirmed (or your policy equivalent), not on Pending. Handle Expired for abandoned checkouts without granting access.
Reconciliation flow: Daily job compares Confirmed payments to recognized revenue. Paid-but-not-confirmed subscriptions stay in a visible exception state.
Webhook handling: Idempotent consumer updates plan tier. Retries must not double-extend billing periods.
Finance considerations: Recognize revenue when your policy says final — often Confirmed, not first detection. Document FX and rail fees separately if applicable.
Support & escalation: Support searches by order id and payment_id. Escalations for “paid but locked out” usually mean lifecycle mapping drift, not portal magic fixes.

marketplace · settlement

Marketplace settlement (illustrative)

A marketplace separates buyer checkout from seller settlement with explicit lifecycle and review boundaries.

Example operational flow — legal and marketplace models vary widely.

Merchant goal: Collect buyer funds with clear states while seller payouts follow separate operational controls.
Integration pattern: Marketplace backend creates payments per order; seller balances update only through documented transitions.
Lifecycle handling: Buyer payment may reach Confirmed before seller withdrawal eligibility. Do not collapse buyer and seller ledgers.
Reconciliation flow: Match order lines to lifecycle states; hold disputed orders in exception queues until policy clears them.
Webhook handling: Separate internal events for buyer Confirmed vs seller withdrawal initiated. Deduplicate aggressively on retries.
Finance considerations: Treasury tracks float and settlement timing per rail. Withdrawal requests are not instant universal payouts.
Support & escalation: Disputes route to ops with payment_id, state history, and webhook audit — not ad-hoc manual chain transfers from support staff.

wallet · top · up

Wallet top-up (illustrative)

A product credits internal balances after explicit confirmation semantics — not at first mempool sight.

Example operational flow — custody and balance models are deployment-specific.

Merchant goal: Let users add funds with operational visibility and supportable state definitions.
Integration pattern: Mobile or web UI calls your backend; backend creates payment and polls or subscribes via webhooks for updates.
Lifecycle handling: Show Pending and Paid distinctly in UI copy. Credit spendable balance on Confirmed per your policy.
Reconciliation flow: Nightly compare internal balance ledger to Confirmed top-ups. Investigate stuck Paid states past thresholds.
Webhook handling: Consumer updates balance idempotently. Late Confirmed after user complaint triggers exception workflow, not silent overwrite.
Finance considerations: Treat top-ups as liabilities until your policy marks them settled. Do not promise instant finality across all rails.
Support & escalation: Support scripts reference lifecycle states, not “blockchain says sent.” Escalate stuck Paid to engineering with payment_id.

invoice · collection

Invoice collection (illustrative)

Accounts receivable issues a crypto payable tied to an invoice id with explicit expiry and reconciliation.

Example operational flow — not tax or legal advice.

Merchant goal: Close invoices when policy-defined finality is met — with audit-friendly state history.
Integration pattern: ERP or billing system creates payment via API; payer pays to returned instructions; webhooks update invoice status.
Lifecycle handling: Invoice open → Pending payment → Paid (detected) → Confirmed (final) or Expired. Partial payments may need custom handling.
Reconciliation flow: AR team matches Confirmed payments to open invoices. Expired attempts require re-issue or manual follow-up — not silent reuse.
Webhook handling: Invoice consumer is idempotent. Duplicate webhook must not mark paid twice on split-payment mistakes.
Finance considerations: Revenue recognition follows Confirmed mapping. FX and fees documented per your treasury rules.
Support & escalation: Collections uses payment_id in comms. “Wrong amount sent” cases land in exception queue — not automatic write-off.

Merchant approval — Gates production access and configuration so integrations match risk, geography, and rails you can support.
Selected rails — Enables only agreed networks and assets — failures at creation are preferable to silent partial support.
Confirmation depth — Separates detection from finality so finance and engineering do not share one overloaded “paid” boolean.
Operational controls — Withdrawal and sensitive actions follow policy — discipline that reduces unbounded automated movement.
Signed webhooks — Forces server-side verification before internal mutation — a boundary, not a convenience feature.

Onboarding coordination. Intake, technical review, and environment enablement are coordinated — not a single anonymous signup button.
Integration iteration. Expect multiple webhook test cycles, idempotency fixes, and mapping clarifications across environments before steady production traffic.
Webhook monitoring. Monitor non-2xx delivery, signature failures, and consumer error rates on your side. Operational drift surfaces in logs before treasury escalations.
Escalation paths. Engineering owns verification and consumers; finance owns recognition rules and exception queues. Route with payment_id — not wallet access.

Full walkthroughs: /operations · Request access