Architecture

How a payment travels from the buyer’s wallet to yours, and why the order is only fulfilled once it really has.

A payment, step by step

1. The order

   The buyer chooses Pybara at checkout. Your store creates the order with a random value of its own, kept on your server, which ties the payment to that order.

2. The checkout frame

   Pybara Wallet’s checkout opens in a frame on your page. Before showing any amount, it checks that your site’s _pybara-payto DNS record lists your wallet, and that the payment is for the page’s own address.

3. Wallet and token

   The buyer connects Pybara Wallet or OISY, and picks a token: ICP, ckBTC, ckETH, ckUSDC or ckUSDT. The order total is converted at the current rate.

4. The payment

   The buyer’s wallet sends the tokens to the settle canister, into a deposit account derived from your account and the order’s value: the deposit can only ever be paid to you, and only once.

5. The split

   Settle checks the deposit on the token’s ledger, then splits it: Pybara’s fee, out of which the network fees are paid, and the rest to your wallet. It then records the payment in Pybara’s logs.

6. Fulfilment

   Your store’s server confirms the payment from Pybara’s logs, by the order’s deposit account, never from what the buyer’s browser reports. Only then is the order marked as paid.

Overview

Buyer's wallet ──► Settle canister ──► Your wallet
                        │
                        ▼
                   Pybara's logs ◄── Your store's server checks the order

Guarantees

• Paid to the wallet your DNS lists: the checkout refuses any other.
• Bound deposits: a deposit is tied to your account and to one order, so it can be neither redirected nor settled twice.
• An immutable split: the settle canister is blackholed, so no one, not even Pybara, can change its code, and it refuses any fee outside 1–3%.
• Verified before fulfilment: an order is marked as paid from Pybara’s on-chain records, not from the page.