A checkout without custody

Crypto checkout with direct-to-wallet settlement.

Payclave coordinates the customer payment experience and keeps merchant payment records, but it does not hold merchant or customer funds, manage private keys, or require a later Payclave payout.

Merchant-controlled wallet

Settlement goes to the receiving wallet configured by the merchant, not to a Payclave wallet controlled on the merchant's behalf.

No Payclave payout step

Funds received by the merchant do not first pass through a Payclave-held account.

Independent verification

The invoice status is based on onchain settlement checks rather than a customer browser claim or provider response alone.

From order to payment record

A checkout flow with a verifiable outcome.

  1. 1

    Merchant configures its wallet

    The merchant supplies a receiving wallet it controls for the supported Polygon stablecoin settlement asset.

  2. 2

    Payclave creates the checkout record

    A hosted checkout session binds the merchant's order reference, amount, mode, and expiry to a public payment URL.

  3. 3

    Customer authorizes the payment

    The customer uses its own wallet or follows one-time payment instructions; Payclave never receives the customer's private key.

  4. 4

    Merchant receives a verified outcome

    Payclave records onchain evidence and sends the signed status event used by the merchant's fulfillment system.

What non-custodial means in a merchant checkout

Non-custodial means Payclave does not take possession of customer or merchant funds and does not control the keys required to move them. The customer authorizes payment from a wallet or sends to the checkout instructions, and settlement is directed to the merchant's configured receiving wallet.

Payclave still provides software around that transfer: checkout sessions, invoices, payment records, independent verification, webhook delivery, retry logs, and audit events.

Why verification remains necessary

Direct settlement does not remove operational failure cases. A customer can choose the wrong token or network, send too little, pay after expiry, submit an unconfirmed transaction, or attempt to reuse a transaction hash.

Payclave evaluates those conditions before marking the invoice paid. Underpaid, overpaid, failed, duplicate, and expired outcomes remain visible rather than being collapsed into a generic success state.

What the merchant still controls

The merchant remains responsible for safeguarding the receiving wallet and its recovery material. Because Payclave cannot move funds from that wallet, any refund must be initiated by the merchant from a wallet it controls.

The merchant also owns its order and fulfillment rules. Payclave supplies an authenticated payment event and status API; the merchant decides what to deliver and ensures webhook processing is idempotent.

Frequently asked questions

Questions about non-custodial checkout.

Is Payclave a wallet?

No. Payclave does not create an internal customer wallet, store private keys, or act as the merchant's wallet. Merchants configure a receiving wallet they control.

Does non-custodial checkout still include payment records?

Yes. Payclave stores checkout sessions, invoices, transaction references, payment outcomes, webhook attempts, and audit events. Those software records describe payments; Payclave does not hold the funds they describe.

Can Payclave reverse a completed payment?

No. Payclave does not control the merchant wallet and cannot reverse an onchain transfer. A merchant-approved refund must be sent separately by the merchant.

How is a direct payment matched to an order?

The checkout session links the merchant's reference and invoice amount to the payment flow. Independent verification and the resulting signed webhook carry the identifiers needed for reconciliation.

Test the flow

Create a checkout session before you change your production stack.

Use test keys, the API playground, and signed webhook examples to validate the complete order-to-payment flow.