Skip to main content
Taberna is a payments API for digital goods. You create a charge, send the buyer to a hosted payment page, and Taberna tells you when the money lands on-chain. Everything is priced in fiat — USD or EUR — and paid in crypto. The buyer sees $50.00, picks a token at checkout, and Taberna handles the exchange-rate conversion, the deposit address, and the on-chain watching. You never touch a wallet, an RPC node, or a price feed.

Accept a payment in six steps

Create a store, add a product, mint a key, POST /v1/orders, redirect, fulfil on the webhook.

Browse the API

Every endpoint, generated from the running service’s OpenAPI document.

​
What you get

13 payment methods across 5 chains. Native coins and stablecoins on Solana, Ethereum, Base, Polygon and BNB Chain. You choose which ones your store accepts; the buyer picks from that list. Settlement to your own wallet. You register a payout address per chain. Each payment lands in a fresh deposit wallet that Taberna generates for that one attempt, and is then swept on-chain to your address. There is no Taberna balance to withdraw from and no payout schedule to wait on. One processing fee, and nothing else. The standard rate is 3%, set per store and visible in the dashboard. It is deducted on-chain during the sweep, so you receive the payment amount minus your rate. The buyer pays their own network fee to send the payment; the sweep’s gas is paid by Taberna, not out of your funds. Processors that quote a percentage and then add network or withdrawal fees on top deduct more than one line — here the processing fee is the whole deduction. See Settlement. A hosted checkout you don’t have to build. Coin selection, live exchange rates, the deposit address and QR, confirmation progress, receipts and digital delivery are all handled on Taberna’s pages.

​
Core concepts

Your merchant account. A store owns products, invoices, API keys, payout wallets, and one webhook endpoint. Everything an API key can reach belongs to exactly one store — the key carries the store identity, so you never pass a store id to /v1 endpoints.
A fixed-price item in your catalogue, with an optional digital delivery attached (a pool of licence keys, a shared file, a redirect). Orders are always for products. See Products and delivery.
A cart of one or more products, each with a quantity. Created through POST /v1/orders, it returns a checkoutUrl to send the buyer to. Expires 30 minutes after creation unless you widen the window. See Orders.
A bill with line items and amounts you compose per request — no product setup. The right tool whenever the amount is decided at request time. Carries a per-store sequential number, arbitrary metadata, and its own hosted page. See Invoices.
A short-lived payment session under an order or an invoice. It is created when the buyer picks a token: Taberna locks a crypto quote for up to 30 minutes on a freshly generated deposit wallet and watches the chain. If the quote lapses unpaid, the parent order or invoice stays payable and the buyer simply picks a token again. See Payment lifecycle.
The buyer-facing hosted page, plus the unauthenticated /v1/checkouts endpoints that drive it. One resource serves both orders and invoices, keyed by the public short id. See Checkout.
A bearer token bound to one store, carrying an explicit set of scopes — the set of /v1 endpoints it may reach. There is no implicit full-access key. See Authentication.
One HTTP endpoint per store that Taberna POSTs lifecycle events to, signed with HMAC-SHA256 and retried for days on failure. This is the completion signal you should build on. See Webhooks.

​
Two ways to charge

Best when you sell a fixed set of things at fixed prices — plans, tiers, licences, downloads.Create the products once (in the dashboard), then reference them by id:
Taberna computes the total, reserves any finite delivery stock for the order’s lifetime, and attaches the delivery to the completed order.

​
Dashboard versus API

The split is deliberate: anything that configures the store is a human action in the dashboard; anything that transacts is available to your server.
There is no API-key route to create products, stores, invoice templates or API keys. That is a current limitation, stated plainly in Errors and limits.

​
Conventions

These hold everywhere in the API, in both directions.

​
Base URL

Programmatic endpoints live under the versioned /v1 prefix. The buyer-facing hosted pages live on a separate host, and Taberna returns their full URLs (checkoutUrl for orders, url for invoices) when you create the resource — never construct them yourself.