Payments & Commerce

Payment infrastructure.
From checkout to reconciliation.

Build payment links and checkout flows your operations team can support. Follow provider responses, delivery, and reconciliation in the same purchase journey, with a clear path for investigating pending payments and repeated notifications.

See how it works ↓Discuss your deployment

Scoped access · Check the exact operation and deployment.

Purchase journeyPaid, delivered, or still waiting?
  1. Checkout request
  2. Payment outcome
  3. Delivery review
Illustrative workflow · availability and access controls apply
A familiar challenge

The checkout finished, yet the customer is still waiting. Your team needs to establish whether payment, notification, or delivery needs attention.

A more useful way forward

Connect the purchase history without confusing a browser redirect with confirmed payment or successful fulfillment.

See a practical example ↓
Why it matters

Help customers pay. Help your team follow through.

For merchants, marketplace operators, and payment developers.

Keep the request connected

Tie the customer’s checkout to the amount, currency, and commercial operation it is meant to complete.

Separate paid from fulfilled

A provider response and delivery of the purchased item are distinct events. Keep both visible.

Make exceptions explainable

Follow pending, failed, or repeated callbacks through a retained payment and reconciliation history.

Core capabilities

The capabilities behind the outcome.

Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.

  • Payment links and checkout

    Create the supported request or session for the intended purchase and merchant context.

  • Provider and currency routing

    Select from the providers, currencies, and routes enabled for your deployment.

  • Callbacks and fulfillment

    Verify notifications and resolve payment state before authorizing delivery in your system.

  • Payment exceptions

    Review pending, failed, or repeated events alongside the order and reconciliation history.

Inspect public records Review documented operations

Public records illustrate inspectable data; they are not customer results or confirmation of production activation.

How Payments & Commerce works

A payment flow your back office can follow.

  1. 01
    Create the request

    Choose an enabled provider and currency, and create the relevant payment link or checkout session for your customer.

  2. 02
    Resolve the payment

    Follow the provider response and permitted settlement evidence. Do not infer completion from a redirect or a customer’s browser alone.

  3. 03
    Deliver and reconcile

    Use the authoritative outcome to coordinate fulfillment and callbacks, then reconcile the payment with your own order records.

A practical example · illustrative

A marketplace sells a digital entitlement.

The buyer checks out while the merchant needs to know whether payment and delivery have both completed.

Request
Bind the checkout to the intended purchase and enabled payment route.
Confirm
Inspect the payment outcome before authorizing the delivery workflow.
Follow through
Handle repeated notifications safely and retain the delivery result alongside the payment.
What the team takes away

A purchase history that explains both the money state and the customer’s delivery state.

Scoped access

Plan your first deployment.

Start with the provider, currency, merchant context, and checkout operation enabled for your deployment. External-provider checkout is distinct from native MPC-funded value movement.

Before your first integration

  • Select one merchant, provider, currency, and purchase workflow.
  • Agree what counts as paid, delivered, and reconciled.
  • Test repeated callbacks, abandoned checkout, and payment-without-delivery cases.
Review the integration Check the API contract
Open workspace
Questions before you build

Payments & Commerce, explained.

Does this require native MPC funding?

Not every checkout flow does. Enabled external-provider commerce can have a separate operating path; native wallet signing and value movement retain their own gates.

Can a callback be treated as permission to fulfill?

Verify its signature and freshness, resolve the authoritative payment state, and process it idempotently. Your receiver remains responsible for authorizing its own side effects.

What should we agree before starting a pilot?

Use the product-specific checklist above to define scope and acceptance tests. Ask the team to confirm the deployment environment, access, supported operations, integration responsibilities, support arrangements, and commercial terms. Availability labels are not a pricing quote or a service-level commitment.

Explore the technical architecture and walkthroughs

Optional deeper reading. Demonstrations are illustrative, not live operational status or a promise of activation. Use the availability guidance above and the current API contract for integration decisions.

INTENT SIGNEDROUTE POLICY BOUNDSETTLEMENT IDEMPOTENTDELIVERY LINKEDCALLBACK ACKNOWLEDGED

THE TRANSACTION IN ACTION

Follow value from intent
to reconciliation.

Select each lifecycle stage to see what the operator knows, what becomes canonical, and which public-safe evidence survives the transaction.

ILLUSTRATIVE PAYMENT ORCHESTRATION
PROOF CHAIN · INTACT
01 · INTENT_CREATED

The commercial agreement becomes canonical.

Amount, accepted currencies, expiry, merchant, customer reference, and callback policy are bound before a payment address or external checkout session is issued.

ORDER
HC-20481
DISPLAY TOTAL
1,280.00 USD
ACCEPTED RAILS
4
EXPIRES IN
14:52
NO PRIVATE PAYMENT CREDENTIALS EXPOSED
1 / 4

SIX ACCOUNTABLE BOUNDARIES

Every handoff
has an owner.

Hybrid-Chain does not flatten payment systems into one vague “paid” state. Each boundary evaluates its own inputs and emits evidence for the next.

01PAYMENT INTENT

Bind the order, merchant, amount, currencies, expiry, return path, and delivery policy before collection begins.

02ROUTE ASSIGNMENT

Issue an exact checkout session or rotating wallet assignment under the admitted currency and network policy.

03RECEIPT & FINALITY

Distinguish detected value from final value and retain the source evidence that satisfied the settlement rule.

04CANONICAL SETTLEMENT

Apply the balance effect once, against one merchant treasury context, with an idempotent canonical reference.

05DELIVERY AUTHORITY

Release goods, services, or digital ownership only after the required payment state becomes independently verifiable.

06RECONCILIATION

Connect money, order, delivery, signed callback, retries, and terminal acknowledgement into one retained outcome.

POLICY BEFORE MOVEMENT

Route the payment
the way the business operates.

Payment method is only one input. Currency exposure, geography, customer identity, merchant risk, settlement preference, wallet capacity, fulfillment policy, and regulatory requirements can all shape the admitted route.

Open payment automation

BUSINESS APPLICATIONS

One payment fabric.
Different commercial models.

Accept, route, reconcile, and prove multi-currency payments. Operate the complete experience, embed selected APIs, or connect payment evidence to the rest of the Hybrid-Chain stack.

01GLOBAL CHECKOUT

Give customers a familiar payment experience while routing card, fiat, stablecoin, and native digital-asset rails through one merchant control plane.

02MARKETPLACE SETTLEMENT

Split the commercial workflow across buyer, operator, seller, fee, delivery, and treasury records without losing the original order context.

03B2B RECEIVABLES

Issue durable payment requests with exact references, accepted currencies, expiry, reconciliation, and signed back-office acknowledgement.

04DIGITAL DELIVERY

Connect settlement to asset ownership, access rights, licenses, subscriptions, or evidence-backed service activation.

05EMBEDDED FINANCE

Expose the payment workflow through APIs and signed callbacks while preserving the operator’s own interface and commercial model.

06REGULATED COMMERCE

Compose identity, transfer compliance, transaction policy, settlement evidence, and operational approval around higher-risk payments.

COMPOSABLE BY DESIGN

Commerce is where
the platform meets the customer.

A payment can call on adjacent control planes without duplicating their security responsibilities. Each integration contributes its own canonical evidence to the commercial outcome.

01NATIVE MPC WALLETS

Threshold-controlled merchant treasury, withdrawal authority, and cross-chain signing.

02FUNDING & SETTLEMENT

Reserve-backed Hybrid balances and burn-before-release discipline for enabled value routes.

03TRANSFER COMPLIANCE

Counterparty, Travel Rule, and exception evidence for policy-scoped transfers.

04AUTOMATION

Signed webhooks, idempotent retries, delivery acknowledgement, and operational reconciliation.

HONEST OPERATING BOUNDARY

Use what is active.
Gate what is not.

External checkout and evidence workflows can operate independently from native value movement. MPC-funded and reserve-backed rails remain subject to their own network, custody, governance, and activation controls.

LIVEPAYMENT INTENTS & CHECKOUT

Issue requests, route through enabled providers, record settlement callbacks, and reconcile orders.

LIVEMULTI-CURRENCY EVIDENCE

Retain exact currency, amount, assignment, delivery, and acknowledgement context.

GATEDNATIVE MPC VALUE MOVEMENT

Available only on networks and funding routes whose wallet, reserve, and settlement gates are active.

Start with one useful result

Make it work for your team.

Bring your workflow. We’ll help identify the scope, access, and acceptance checks for a practical pilot.

Discuss your deployment
Build the next part of your workflow

Connected products.

Start with Payments & Commerce. Review these adjacent capabilities when your requirements call for them.

Plan your integration Discuss a scoped pilot All products