# Create a checkout session
Source: https://docs.suby.fi/v3-beta/api-reference/checkout/create-a-checkout-session
/v3-beta/api-reference/openapi.yaml post /v3/checkout/sessions
Mint a signed hosted-checkout token (`cs_…`). The returned `url` is the page you
send the payer to · the only place a card is ever collected.
**`mode=payment`** · a one-time charge.
**`mode=subscription`** · opens a subscription and bills its first cycle. Needs a
`billingMode: subscription` product
(`CHECKOUT_SUBSCRIPTION_REQUIRES_RECURRING_PRODUCT`), and is required to open one ·
a recurring product sold as `payment` is charged once and never renews. Renewals
are then driven by Suby.
**`mode=setup`** · stores a card without charging, for later off-session debits
(`POST /v3/payments/off-session`). No Payment is created. Requires a `pay_as_you_go`
`productId`, which names what the payer authorises without pricing the page. A
priced product here is refused (`CHECKOUT_SETUP_REQUIRES_PER_USE_PRODUCT`), a
per-use one on any other mode too (`PRODUCT_PRICED_PER_USE`).
# Retrieve a checkout session
Source: https://docs.suby.fi/v3-beta/api-reference/checkout/retrieve-a-checkout-session
/v3-beta/api-reference/openapi.yaml get /v3/checkout/sessions/{token}
Re-hydrate a signed session. An expired token returns 200 with
`status=EXPIRED`.
Pass the **`token`** from the create response (or the `cs_…` segment of
`url`) · *not* `id`. Sessions are stateless: the payload is carried in
the token itself, so a bare id has nothing to verify against and returns
`400 CHECKOUT_SESSION_NOT_FOUND`.
# Chains and tokens this account accepts
Source: https://docs.suby.fi/v3-beta/api-reference/crypto/chains-and-tokens-this-account-accepts
/v3-beta/api-reference/openapi.yaml get /v3/crypto/assets
Scoped to the caller, not the global catalogue. A headless integration built
off the full catalogue offers assets the merchant never enabled, and the
payer only finds out when the charge is refused.
Tokens come nested under their chain. A chain's name, icon and payable
`modes` are facts about the CHAIN, so they are stated once per chain
rather than repeated on every token · the payload grows with the number
of chains, not with the catalogue.
`modes` says how a chain's tokens can actually be paid. Bitcoin is
deposit-only · it has no contracts to sign against · so a UI that renders
a "connect wallet" button on it builds a flow the API refuses.
SANDBOX returns testnet chains, LIVE mainnet: a sandbox integration is
never handed a mainnet address to send real funds to.
**Send the amount you are about to charge** (`priceCents` + `currency`) and the
answer is what that payment can use, rather than what the account accepts in
general. Two things narrow it: a chain whose network fees the amount cannot
clear (Bitcoin's minimum is $50 · under it the fee takes most of the payment),
and, on an account that converges every payment into one settlement asset, a
chain no bridge can route out of. Both are refusals the charge would raise
anyway · asking with the amount is how you keep them off the payer's screen.
# Create a crypto charge
Source: https://docs.suby.fi/v3-beta/api-reference/crypto/create-a-crypto-charge
/v3-beta/api-reference/openapi.yaml post /v3/crypto/charges
The headless rail · render the flow inside your own site, no PCI scope.
Returns the charge plus the `instruction` that completes it · `qr_deposit` an
address and the exact amount (BIP21 URI on Bitcoin), `wallet_connect` calldata to
sign (ABI-encoded on EVM, base64 transaction on Solana).
**Poll `GET /v3/payments/{id}`** · its `deposit` envelope carries `expected` /
`received` / `remaining` and a confirmations counter.
Settlement routing is an account setting, not a field here. One consequence: an
account converging to a stablecoin on another chain takes `qr_deposit` only ·
`wallet_connect` answers `CRYPTO_AUTOSWAP_MODE_NOT_SUPPORTED`.
# Price a fiat amount in a token
Source: https://docs.suby.fi/v3-beta/api-reference/crypto/price-a-fiat-amount-in-a-token
/v3-beta/api-reference/openapi.yaml get /v3/crypto/quote
**Indicative.** The authoritative amount is the one frozen onto the charge
when you create it. A quote fetched a minute earlier is a display value, and
treating it as the amount due is how a volatile-asset payment lands short.
There is no way to supply the token amount yourself: quoting is exactly
where a caller-supplied number would let a payer decide what they owe.
Volatile assets already carry their buffer in `tokenAmount`.
# Create (or get) a customer
Source: https://docs.suby.fi/v3-beta/api-reference/customers/create-or-get-a-customer
/v3-beta/api-reference/openapi.yaml post /v3/customers
Get-or-create by email. Returns 201 for a new customer, 200 if one with that email already exists.
# List customers
Source: https://docs.suby.fi/v3-beta/api-reference/customers/list-customers
/v3-beta/api-reference/openapi.yaml get /v3/customers
# Retrieve a customer
Source: https://docs.suby.fi/v3-beta/api-reference/customers/retrieve-a-customer
/v3-beta/api-reference/openapi.yaml get /v3/customers/{id}
# Create a discount code
Source: https://docs.suby.fi/v3-beta/api-reference/discount-codes/create-a-discount-code
/v3-beta/api-reference/openapi.yaml post /v3/discount-codes
Mint a promo code. It is redeemed at checkout · carried by the session as `discountCode`, applied on its own when `preApply` is set, or typed by the payer · and always re-validated and re-priced server-side. A payer never sets an amount.
# Delete a discount code
Source: https://docs.suby.fi/v3-beta/api-reference/discount-codes/delete-a-discount-code
/v3-beta/api-reference/openapi.yaml delete /v3/discount-codes/{id}
Hard delete. Payments that already redeemed the code keep their recorded discount.
# List discount codes
Source: https://docs.suby.fi/v3-beta/api-reference/discount-codes/list-discount-codes
/v3-beta/api-reference/openapi.yaml get /v3/discount-codes
# Retrieve a discount code
Source: https://docs.suby.fi/v3-beta/api-reference/discount-codes/retrieve-a-discount-code
/v3-beta/api-reference/openapi.yaml get /v3/discount-codes/{id}
# Update a discount code
Source: https://docs.suby.fi/v3-beta/api-reference/discount-codes/update-a-discount-code
/v3-beta/api-reference/openapi.yaml patch /v3/discount-codes/{id}
Partial update. Changing `discountType` rewrites the whole type block · the opposite kind's fields are cleared. `isActive: false` stops a code without deleting it: already-issued links then fail with `DISCOUNT_CODE_INACTIVE` rather than silently charging full price.
# API Reference
Source: https://docs.suby.fi/v3-beta/api-reference/overview
The Suby.fi v3 REST API · base URL, auth, and conventions.
The v3 API is organized around REST. Resources are plural and live under the
`/v3` prefix. All requests are authenticated with your
[API key](/v3-beta/authentication) in the `X-Suby-Api-Key` header.
* **Base URL** · `https://api.beta.suby.fi`
* **Auth** · `X-Suby-Api-Key: sk_live_…` (or `sk_sandbox_…`)
* **Envelope** · `{ "success": true, "data": … }` / `{ "success": false, "error": …, "message": … }`
* **Money** · every field ends in `Cents` and carries a string of digits (`"1999"` = 19.99); token amounts likewise, in smallest unit
* **Pagination** · cursor-based (`?limit=`, `?cursor=` → `pagination.nextCursor`)
See [Errors & responses](/v3-beta/errors) for status codes and error codes.
## Resources
| Group | Description |
| - | - |
| **Checkout** | Signed hosted-checkout tokens. Where every payment starts, and the only place a card is collected. |
| **Payments** | Read, refund, receipts · plus the off-session debit of a stored card (pay-as-you-go) and crypto. |
| **Subscriptions** | Drive a live subscription: read it, change its plan, end it. Opened by a checkout session. |
| **Products** | The catalogue. A `recurringInterval` is what makes a product a plan. |
| **Customers** | Customer records and billing address. |
| **Payment Methods** | Read and revoke stored cards. They are created by a checkout session. |
| **Discount Codes** | Promo codes, redeemed at checkout. |
| **Licences** | Called by the buyer's software · the licence key is the credential, so no API key is sent. |
Analytics, checkout branding, webhook-endpoint management and post-payment access
configuration live in the dashboard. Webhooks are still emitted · only choosing
where they go left the API.
Pick an endpoint from the sidebar to see its parameters, request body, and
response schema, with a live "Try it" panel.
# Debit a stored card, off-session
Source: https://docs.suby.fi/v3-beta/api-reference/payments/debit-a-stored-card-off-session
/v3-beta/api-reference/openapi.yaml post /v3/payments/off-session
Debit a card already stored here, no payer present · metered billing, top-ups,
a usage threshold crossed.
`productId` says what was consumed, `priceCents` how much. The product must be
`billingMode: pay_as_you_go` (422 `PRODUCT_NOT_PRICED_PER_USE` otherwise) and
the currency comes from it.
Collecting a NEW card is not possible here · open a checkout session.
Crypto has its own endpoint, `POST /v3/crypto/charges`.
# Get the receipt (JSON)
Source: https://docs.suby.fi/v3-beta/api-reference/payments/get-the-receipt-json
/v3-beta/api-reference/openapi.yaml get /v3/payments/{id}/receipt
# Get the receipt (PDF)
Source: https://docs.suby.fi/v3-beta/api-reference/payments/get-the-receipt-pdf
/v3-beta/api-reference/openapi.yaml get /v3/payments/{id}/receipt.pdf
Renders the receipt to a downloadable PDF invoice. Returns the raw PDF
bytes (`application/pdf`) · **not** the JSON envelope.
The invoice **issuer** ("From") depends on your settlement mode: on
Merchant-of-Record accounts Suby is the legal seller, so the invoice is
always issued by **Suby SAS** and your business
appears on the "Fulfilled by" line.
# List payments
Source: https://docs.suby.fi/v3-beta/api-reference/payments/list-payments
/v3-beta/api-reference/openapi.yaml get /v3/payments
# Refund a captured payment
Source: https://docs.suby.fi/v3-beta/api-reference/payments/refund-a-captured-payment
/v3-beta/api-reference/openapi.yaml post /v3/payments/{id}/refund
Refund a captured card/APM payment. Omit `refundCents` for a full refund of the remaining amount. Crypto is not refundable · funds settle on-chain (`PAYMENT_NOT_REFUNDABLE`).
**Read `refund`, not `payment.status`.** The row flips to `REFUNDED` / `PARTIALLY_REFUNDED` only when the money moves, on the acquirer's confirmation and in the same transaction as the balance debit · so `payment.status` usually still reads `COMPLETED` here. `refund.paymentStatusAfter` says where it lands, and the `payment.refunded` / `payment.partially_refunded` webhook fires when it does.
# Retrieve a payment
Source: https://docs.suby.fi/v3-beta/api-reference/payments/retrieve-a-payment
/v3-beta/api-reference/openapi.yaml get /v3/payments/{id}
# Create a product
Source: https://docs.suby.fi/v3-beta/api-reference/products/create-a-product
/v3-beta/api-reference/openapi.yaml post /v3/products
# List products
Source: https://docs.suby.fi/v3-beta/api-reference/products/list-products
/v3-beta/api-reference/openapi.yaml get /v3/products
# Put a product back on sale
Source: https://docs.suby.fi/v3-beta/api-reference/products/put-a-product-back-on-sale
/v3-beta/api-reference/openapi.yaml post /v3/products/{id}/unarchive
Move the product back to `ACTIVE`. Empty body.
# Retrieve a product
Source: https://docs.suby.fi/v3-beta/api-reference/products/retrieve-a-product
/v3-beta/api-reference/openapi.yaml get /v3/products/{id}
# Take a product off sale
Source: https://docs.suby.fi/v3-beta/api-reference/products/take-a-product-off-sale
/v3-beta/api-reference/openapi.yaml post /v3/products/{id}/archive
Move the product to `ARCHIVED` · no longer sellable, subscriptions already running
keep renewing. Nothing is ever deleted: a receipt from last year still has to
render. Empty body.
# Update a product
Source: https://docs.suby.fi/v3-beta/api-reference/products/update-a-product
/v3-beta/api-reference/openapi.yaml patch /v3/products/{id}
Partial update · send only what changes. The recurring cadence is fixed at create.
**Editing `priceCents` does not re-price existing subscribers** · each bills the
price frozen when they subscribed. Move them with
`POST /v3/subscriptions/{id}/change-plan`.
# Call off a scheduled plan change
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/call-off-a-scheduled-plan-change
/v3-beta/api-reference/openapi.yaml post /v3/subscriptions/{id}/cancel-plan-change
Drop a queued plan change that has **not taken effect yet** · typically a downgrade scheduled at the period end. Nothing charged, nothing refunded: the next renewal bills the plan the subscription runs today.
Read what is queued from `GET /v3/subscriptions/{id}` → `scheduledChange`. Pass `scheduledChangeId` to have the call refused if it no longer names that change.
**An immediate upgrade cannot be called off** once its charge is in flight (`409 PLAN_CHANGE_NOT_CANCELABLE`) · refund it and `change-plan` back instead. One whose charge was refused never applied, and clears here.
`change-plan` back to the current `productId` undoes nothing · `409 SAME_PLAN`.
# Cancel a subscription
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/cancel-a-subscription
/v3-beta/api-reference/openapi.yaml post /v3/subscriptions/{id}/cancel
# Change the expiration date
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/change-the-expiration-date
/v3-beta/api-reference/openapi.yaml post /v3/subscriptions/{id}/period-end
Move the end of the current paid period (`currentCycleDueAt`, `expires_at` in webhooks)
of an `ACTIVE` subscription.
This date is both when access ends and when the next renewal happens, so both move.
The access grants the subscription issued (Discord role, Telegram membership…) follow
the new date. Fires `subscription.updated`.
The date must be in the future. A date **earlier** than the current one takes back days
the customer already paid for and is refused with `409 PERIOD_END_SHORTENING_UNCONFIRMED`
unless you pass `allowShorten: true`.
# List subscriptions
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/list-subscriptions
/v3-beta/api-reference/openapi.yaml get /v3/subscriptions
There is no `POST /v3/subscriptions`. A subscription opens from a checkout
session in `mode: "subscription"` on a `billingMode: subscription` product.
Starting one here meant sending a card token in the request body, which is
not a shape this API accepts.
These routes drive a subscription that already exists.
# Retrieve a subscription
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/retrieve-a-subscription
/v3-beta/api-reference/openapi.yaml get /v3/subscriptions/{id}
# Retry a failing renewal now
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/retry-a-failing-renewal-now
/v3-beta/api-reference/openapi.yaml post /v3/subscriptions/{id}/retry-renewal
Bring the next dunning attempt forward on a `PAST_DUE` subscription.
**It does not charge.** It moves `nextRenewalAttemptAt` to now and the renewal sweep
makes the attempt it was already going to make, on the same retry budget. Listen for
`subscription.*` for the outcome. Anything other than `PAST_DUE` answers `422`.
# Upgrade or downgrade the plan
Source: https://docs.suby.fi/v3-beta/api-reference/subscriptions/upgrade-or-downgrade-the-plan
/v3-beta/api-reference/openapi.yaml post /v3/subscriptions/{id}/change-plan
Switch to a different recurring product · the direction follows the price.
**Upgrade** → immediate, customer-present. `useCustomerPaymentMethod: true` charges the card saved at the first cycle (3DS can still surface), otherwise pass `method` + `card.tokenizedInstrument`. Same cadence charges the prorated difference, a different one the full new price with the anchor reset. Answers `202`, `applied: false` · the swap lands when that charge completes.
**Downgrade** → scheduled at the period end. No charge, no card.
**No webhook announces the swap** · re-read `GET /v3/subscriptions/{id}`: queued under `scheduledChange`, applied once that is `null`.
The target must be ACTIVE, recurring, and in the current currency (cadence may differ). MoR VAT is recomputed on it at charge time.
# Authentication
Source: https://docs.suby.fi/v3-beta/authentication
Authenticate v3 requests with your Suby.fi API key.
Send your secret key in the `X-Suby-Api-Key` header on every request.
```bash theme={null}
curl https://api.beta.suby.fi/v3/payments \
-H "X-Suby-Api-Key: sk_live_your_key_here"
```
## Keys
Generate keys in [dashboard settings](https://dashboard.suby.fi/dashboard/settings). A key is shown **once** · store it in a secret manager, never in client-side code or a repo.
| Prefix | Environment | Behaviour |
| - | - | - |
| `sk_live_…` | Production | Real processing, real funds. |
| `sk_sandbox_…` | Sandbox | Fully simulated. No real money. |
The environment comes from the prefix · there is no environment header. LIVE and sandbox data are isolated.
Treat `sk_live_…` like a password. If it leaks, rotate it from the dashboard.
Suby will never ask you for it.
## Sandbox
* **Cards** · test numbers, e.g. `4242 4242 4242 4242`.
* **Crypto** · Base Sepolia only (`chainId` `84532`). Auto-selected if you specify nothing.
* **Refunds** · skip the provider, mark the payment `REFUNDED` directly.
* **Saving a card** · a `setup` session with the test card stores a `pi_…` you can then debit off-session.
* **Webhooks** · fire normally.
## Failures
`401` on a missing or invalid key, `429` when rate-limited (per key · back off and retry).
```json theme={null}
{ "success": false, "error": { "code": "UNAUTHORIZED", "message": "Invalid or missing API key" } }
```
# Customer Portal
Source: https://docs.suby.fi/v3-beta/docs/customers/customer-portal
Your customer portal gives you access to all your subscriptions, payments, and product access in one place. No need to contact anyone · everything is fully self-serve.
## Access Your Customer Portal
Your customer portal is available at **customer.suby.fi** and is linked to the email you used at checkout. You can also access it directly from any payment email Suby sent you.
Open [customer.suby.fi](https://customer.suby.fi), or click the customer portal link inside any **Payment Receipt** email from Suby.
![Capture D’écran 2026 05 07 À 18 15 55]()
Use the same email you used at checkout. No password required.
View your subscriptions, check your payment history, claim your access, or cancel a subscription.
Make sure to use the exact email associated with your purchase. If you used a different email at checkout, the portal won't show your subscriptions.
## I Can't Find My Payment Receipt
If you can't locate the email:
* Check your **spam or junk folder**
* Search for **"Payment Receipt"** or **"Suby"** in your inbox
* Make sure you are searching in the correct email account, the one you used at checkout
## I Still Need Help
If you are unable to access your portal or have an issue with your subscription, contact the Suby support team.
Reach us on WhatsApp, Telegram, Discord, or email.
# How to Cancel a Subscription
Source: https://docs.suby.fi/v3-beta/docs/customers/how-to-cancel-a-subscription
Cancel your subscription at any time from the customer portal.
You can cancel your subscription at any time from your customer portal. No need to contact anyone · the process is fully self-serve.
## Access Your Customer Portal
Your customer portal is accessible via the **Payment Receipt** email Suby sent you when you subscribed.
Search for "Payment Receipt" in the inbox associated with your purchase. If you can't find it, check your spam or junk folder.
Click the customer portal link inside the email. No password required.
Find the active subscription you want to cancel and click **Cancel**.
Your access remains active until the end of your current billing period. You will not be charged again after cancellation.
## I Can't Find My Payment Receipt
If you can't locate the email:
* Check your **spam or junk folder**
* Search for **"Payment Receipt"** or **"Suby"** in your inbox
* Make sure you are searching in the correct email account, the one you used at checkout
## I Still Need Help
If you are unable to cancel or have an issue with your subscription, contact the Suby support team.
Reach us on WhatsApp, Telegram, Discord, or email.
# Why Did Suby Charge Me?
Source: https://docs.suby.fi/v3-beta/docs/customers/why-did-suby-charge-me
Understanding charges from Suby on your bank statement or card.
If you see a charge from Suby on your bank statement or card, it means you made a purchase through a product or service that uses Suby as its payment processor.
Suby is a payment platform used by independent sellers. We process the payment on their behalf, we are not the company whose product you purchased.
## Common Reasons for a Charge
You completed a one-time purchase through a seller using Suby as their payment provider. The charge reflects the amount you paid at checkout.
If you subscribed to a recurring product, weekly, monthly, or yearly, your card was charged automatically at the end of your billing cycle. This is expected behavior for active subscriptions.
If a previous renewal attempt failed, Suby may have retried the charge once your payment method was updated or became available again.
## I Don't Recognize This Charge
If you don't recognize the charge, here are a few things to check:
* Did someone else with access to your card make a purchase?
* Do you have an active subscription you may have forgotten about?
* Did you sign up for a free trial that has since ended?
Suby does not initiate charges without an active product or subscription tied to your account. All charges correspond to a real transaction.
## Find Your Payment Receipt
Every time a payment goes through, Suby sends a **Payment Receipt** to the email address used at checkout. This email contains the merchant's details, the amount charged, and a link to your customer portal.
Search for "Payment Receipt" in the email inbox associated with your purchase.
![Email]()
If you can't find it, check your spam or junk folder, payment emails sometimes get filtered.
The receipt contains a link to your customer portal where you can view your subscriptions and manage your account.
## I Want a Refund
Suby does not handle refund requests directly. Refunds are issued by the merchant you purchased from.
To request a refund, contact the seller whose product or service you purchased. Their contact details are included in your Payment Receipt email.
Suby cannot issue refunds on behalf of merchants. Please contact the seller directly.
## I Want to Cancel My Subscription
Your customer portal is accessible directly from your Payment Receipt email. Open the email, click the portal link, and you will be able to cancel your subscription or update your payment method without needing a password.
Can't find the email? Check your spam folder and search for "Payment Receipt" or "Suby".
## I Still Need Help
If you believe you were charged in error or have an urgent issue, you can reach the Suby support team directly.
Reach us on WhatsApp, Telegram, Discord, or email.
# Merchant of Record vs PayFac: Dispute Liability
Source: https://docs.suby.fi/v3-beta/docs/education/MoR-vs-PayFac
Suby offers two settlement modes with the same thresholds and fees in both, but very different risk models for who controls disputes and what's at stake.
Suby offers two ways to process card payments. The reserve and termination thresholds and the \$25 (Visa), \$50 (Mastercard) dispute fees from [Suby's Dispute Thresholds](/v3-beta/docs/education/suby-dispute-thresholds) are the same in both. What differs is who's exposed, and who controls the response.
## Merchant of Record (MoR)
Suby is the **legal seller** on the card statement and the invoice. Every dispute is filed against **Suby's** merchant account, not yours, and it lands in the same ratio Suby reports to Visa and Mastercard, a ratio shared across **every merchant on MoR**, not just you.
* Your reserve-increase and hard-ceiling thresholds (0.5%–0.75%, then 0.75%) are tracked at your account level, but they exist to protect the **shared MoR pool**: one merchant running hot puts every other MoR merchant's processing at risk.
* On MoR, every dispute is **automatically refunded to the customer on receipt, without contestation**, to protect Suby's aggregate dispute ratio with the schemes and acquirers under that model. You may request in writing to move to a contested-dispute process instead, subject to Suby's prior written agreement and possibly different pricing or reserve terms.
* Suby, not you, decides how a dispute is represented by default. You get compliance handled for you, in exchange for less discretion over individual cases.
## PayFac
In PayFac mode you're boarded as your own **sub-merchant** with an identity of your own inside Suby's payment-facilitation relationship with its banking partners. You control how disputes are handled: your refund policy, your evidence and representment strategy.
* Your ratio is tracked **at your own sub-merchant level**, directly with the underlying processing/banking partner. It isn't pooled with other Suby merchants the way MoR is.
* If you cross the same 0.75% hard ceiling, the **partner can flag, restrict, or terminate your specific sub-merchant** independently of everyone else on Suby.
* Because that flag sits with the partner directly, an excessive ratio here risks your standing with that specific banking relationship, and can make future approvals with similar partners harder.
## At a glance
| | Merchant of Record | PayFac |
| - | - | - |
| Legal seller of record | Suby | You |
| Reserve may increase | 0.5% – 0.75% | 0.5% – 0.75% |
| Hard ceiling / possible termination | Above 0.75% | Above 0.75% |
| Dispute fee | \$25 Visa - \$50 Mastercard | \$25 Visa - \$50 Mastercard |
| Ratio measured against | Suby's pooled MoR portfolio | Your individual sub-merchant account |
| Who controls dispute handling | Suby (automatic refund by default) | You |
| Auto-refund to prevent disputes | Yes, applied by default | Optional / configurable by you |
| What's at risk if you exceed the line | Your access to MoR (to protect the shared pool) | Your standing with the specific banking partner |
| Best fit for | Merchants who want dispute risk handled for them | Merchants who want direct control over dispute strategy |
# Disputes & Chargebacks: Overview
Source: https://docs.suby.fi/v3-beta/docs/education/disputes-chargeback
What a dispute is, why it's fundamentally a customer-relationship problem, and how favoring refunds keeps you off Suby's monitoring thresholds.
A **dispute** (chargeback) isn't just a refund. It's a formal complaint filed with the card network. This guide walks through how Suby watches your dispute rate, what it costs you when one is opened, and how that risk is shared between you and Suby depending on whether you run **Merchant of Record (MoR)** or **PayFac**.
## What counts as a dispute
A dispute is opened when a cardholder contacts their **issuing bank**, not you, not Suby, to reject a charge: fraud, "I didn't authorize this," "I canceled and was still billed," "goods/services not as described." The issuer pulls the funds back immediately and the amount is provisionally reversed. You can **represent** the case with evidence, but the dispute itself has already been counted against your rate, win or lose.
This is different from a **refund**, which you or Suby initiate voluntarily before the cardholder escalates. A timely refund never touches your dispute rate. A dispute always does, even one you go on to win.
## It's a customer relationship before it's a ratio
Almost no dispute starts as fraud. It starts as a customer who didn't get what they expected, couldn't find how to cancel, or didn't recognize the charge, and calling their bank felt faster than dealing with you. By the time it's a dispute, they've already given up on reaching a human on your side.
That's why the single biggest lever on your rate isn't a setting or a policy document. It's how easy you make it to get a refund **before** the customer picks up the phone. A refund is always the cheaper, faster, and more repairable outcome, for both of you.
* No dispute fee
* Doesn't touch your 0.5 / 0.75 / 1.0% thresholds at all
* Resolved in minutes. The customer often stays a customer
* **You** stay in control of the outcome
* \$25 (Visa), \$50 (Mastercard) fee, win or lose
* Counts against your rate immediately
* The relationship already broke: they chose their bank over you
* The **issuer** decides the outcome, not you
**Rule of thumb:** the cheapest chargeback is the one that never happens because you refunded first. A generous, visible refund policy and a support team that responds fast aren't just good customer service. They're your most effective dispute-prevention tool, well ahead of anything technical.
A few habits go a long way: make refunds and cancellation self-serve wherever you can, respond to support requests before a customer has time to get frustrated, and if something breaks on your end (an outage, a billing bug, a delayed delivery), proactively refund or credit the affected customers rather than waiting for them to notice and complain.
# Reducing Your Dispute Rate
Source: https://docs.suby.fi/v3-beta/docs/education/reducing-your-dispute-rate
Practical habits to stay under Suby's 0.5% healthy threshold, before the reserve increase and hard ceiling kick in, and how to track disputes as they happen via webhooks.
The same habits keep you under 0.5% regardless of which mode you're on. Most of them come back to what's covered in [Disputes & Chargebacks: Overview](/v3-beta/docs/education/disputes-chargeback): make it easy for an unhappy customer to reach you before they reach their bank.
A clear billing descriptor that matches your product or brand means a cardholder recognizes the charge before calling their bank.
Most disputes start because a refund or cancellation path wasn't obvious, not because of actual fraud.
Respond to `payment.chargeback` the moment it fires, while representment is still possible.
Delivery confirmation and accepted terms win representment. A lapsed, unexpected renewal retry is a common dispute trigger.
## How Suby helps you track disputes
Suby fires a dedicated webhook the moment a dispute is opened, so you can act while there's still time to respond, and your dashboard reflects your live position against the 0.5% (reserve may increase) and 0.75% (hard ceiling) thresholds at all times.
| Event | Fires when |
| - | - |
| `payment.chargeback` | A chargeback was opened against a payment. The \$25 (Visa), \$50 (Mastercard) fee is applied at this point. |
| `payment.refunded` | A payment was fully refunded, including proactive/auto-refunds that prevented a dispute. |
| `payment.partially_refunded` | A payment was partially refunded. |
See the full event catalog, payload shape, and HMAC signature verification.
# Suby's Dispute Thresholds
Source: https://docs.suby.fi/v3-beta/docs/education/suby-dispute-thresholds
Suby's alert, reserve, and termination thresholds, and the per-case dispute fee: the numbers that actually govern your account.
This page describes **Suby's own thresholds**: the numbers that actually govern your account, as set out in your Merchant of Record Agreement. For how these compare to Visa's and Mastercard's own monitoring programs, see [Visa & Mastercard Dispute Programs](/v3-beta/docs/education/visa-mastercard-dispute-programs).
## Your dispute rate
Your dispute rate is your monthly disputes divided by your monthly transactions. Suby tracks it continuously and acts in two stages, well before Visa or Mastercard would ever step in themselves.
Suby may start holding back a larger reserve on your payouts to cover expected dispute losses while you bring the rate back down.
Above 0.75%, Suby may take remedial action, up to and including closing your account and terminating your agreement with immediate effect. This threshold is contractual and not negotiable, since as merchant of record, your transactions count against Suby's own aggregate dispute ratio with the schemes and acquirers.
| Range | Status |
| - | - |
| 0% – 0.5% | Healthy |
| 0.5% – 0.75% | Reserve may be increased |
| Above 0.75% | Remedial action, up to and including account closure and immediate termination (hard ceiling) |
Visa and Mastercard don't consider a merchant "excessive" until 1.5%. Suby's hard ceiling sits at 0.75%, half that level, by design, so you have room to fix a problem before it ever puts your Suby account at network-level risk.
## What a dispute costs you
Every dispute opened against one of your payments carries a flat Suby fee, on top of whatever happens to the disputed amount itself. The fee is charged when the case is opened. It doesn't matter whether you go on to win or lose it, and it's **identical whether you're on Merchant of Record or PayFac**.
**\$25** per case opened
**\$50** per case opened
**Same in MoR and PayFac.** This fee schedule and these thresholds don't change based on your settlement mode. What changes between the two modes is who controls the response and where the compliance risk sits. See [Merchant of Record vs PayFac](/v3-beta/docs/education/MoR-vs-PayFac).
# Visa & Mastercard Dispute Programs
Source: https://docs.suby.fi/v3-beta/docs/education/visa-mastercard-dispute-programs
Background on how Visa's Acquirer Monitoring Program (VAMP) and Mastercard's Excessive Chargeback Program work, and why Suby sets a stricter internal bar.
These are **not your actual limits.** Your limit is the table on [Suby's Dispute Thresholds](/v3-beta/docs/education/suby-dispute-thresholds): reserve may increase between 0.5% and 0.75%, hard ceiling and possible termination above 0.75%. This page is background on the network rules that shape why Suby sets the bar where it does.
Both networks compare your monthly dispute count against your monthly transaction count and enforce tiers on the result. Programs and exact numbers are set by Visa and Mastercard, not by Suby or your acquirer, and they get revised periodically.
## Visa Acquirer Monitoring Program (VAMP)
VAMP replaced the older VDMP/VFMP programs and merges fraud reports (TC40) and disputes (TC15) into a single ratio against settled transactions.
| Tier | Ratio | Consequence |
| - | - | - |
| Excessive | **1.5%** | \~\$8 network fee per disputed/fraud transaction, no warning tier, mandatory remediation |
1.5% has applied since April 1, 2026 (down from 2.2% at launch). Visa also monitors acquirers directly, which is part of why acquirers, including Suby's own banking partners, commonly enforce internal caps well below Visa's published threshold.
## Mastercard Excessive Chargeback Program
Mastercard flags a merchant once **both** a count and a ratio condition are met in a given month (this month's chargebacks divided by last month's transactions).
| Tier | Chargebacks | Ratio | Consequence |
| - | - | - | - |
| Excessive Chargeback Merchant (ECM) | 100–299 | 1.5%–2.99% | Monthly fines, mandatory remediation plan |
| High Excessive Chargeback Merchant (HECM) | 300+ | 3%+ | Escalating fines, \~\$5 issuer recovery assessment per case |
Exiting either tier requires three consecutive months back under the line.
Treat every number on this page as directional. Visa and Mastercard change these thresholds periodically. Visa's merchant "Excessive" tier alone moved from 2.2% to 1.5% on April 1, 2026. Suby's internal hard ceiling of 0.75%, described on [Suby's Dispute Thresholds](/v3-beta/docs/education/suby-dispute-thresholds), sits at half that level, built with headroom against future network tightening.
# Analytics
Source: https://docs.suby.fi/v3-beta/docs/features/analytics
Track your revenue, customers, and growth from your dashboard.
Suby's analytics dashboard gives you a real-time view of your business performance, from a high-level overview down to individual payment attempts. All data is filterable by period and exportable as CSV.
Throughout Analytics, data is always split between **classic payments** (card, Apple Pay, Google Pay, Klarna, bank transfer) and **crypto payments**, so you can see how each side of your business is performing.
![Analytics]()
## Overview
The Overview tab gives you a snapshot of revenue across different views and timeframes.
Switch between gross and net revenue (after fees and refunds), and view cumulative revenue over time.
**1 month**, **3 months**, **1 year**, or a **custom** date range.
Break revenue down by individual product, useful if you have multiple subscription tiers or a mix of one-time and recurring products.
See revenue broken down per customer, to identify your top spenders.
See revenue broken down by country, and split your customer base by country to see where your business is growing.
## Payments
A detailed, transaction-level view of how your payments are performing.
Total completed payments over your selected period.
Every attempt, successful or not, giving you the full funnel.
The share of payment attempts that end up successful.
See which payment methods, card, Apple Pay, Google Pay, Klarna, crypto, your customers use most.
Track decline volume and drill into why payments are declined, insufficient funds, wrong PIN, 3DS not authorized, and other reasons.
A live feed of your most recent transactions, right from the Analytics view.
## Subscriptions
Track recurring revenue and see exactly what's coming up.
Track the number of active subscriptions over time.
See exactly who's getting charged and when, upcoming subscription payments laid out on a calendar. Cancel any subscription directly from the calendar view.
Track how many subscriptions are cancelled or lapse over your selected period.
## Customers
See where your customers are located.
Split your customers between subscription customers and one-time purchasers.
## Time Filters
Filter Overview and other metrics by any of the following periods:
| Period |
| - |
| 1 month |
| 3 months |
| 1 year |
| Custom range |
# Checkout
Source: https://docs.suby.fi/v3-beta/docs/features/checkout
The hosted checkout page Suby generates for every product.
Every product on Suby has a hosted checkout page. When a customer clicks your PayLink or is redirected via a Checkout Session, they land on this page to complete their payment.
![Checkout]()
## What the Checkout Includes
Upload a custom logo image to brand your checkout page.
Displayed prominently at the top. Supports plain text.
Cards, Apple Pay, Google Pay, bank account, and stablecoins, displayed automatically based on what you have enabled.
Price, applicable taxes calculated in real time based on the customer's location, and total before confirmation.
## Setting Up Your Checkout
Open the product in your dashboard and click **New product**.
Upload a banner image and fill in your product name and description.
Changes apply immediately to your live checkout.
## Expiring & Cancelling a Checkout
Checkouts created through the API can be given a lifetime and killed on demand:
* **`expiresAt`** · pass a future date on `POST /api/payment/create` or `POST /api/subscription/create` to set a hard deadline. Once it passes, the link stops loading and no payment attempt can revive it. On subscriptions it applies to the initial checkout only, renewals are unaffected.
* **`POST /api/payment/:paymentId/cancel`** · invalidates a checkout that has not settled yet. The payment becomes `CANCELED` (terminal) and a `CHECKOUT_CANCELED` webhook is sent.
Together they let you issue a replacement checkout (new price, new discount) without the risk of the superseded one being paid alongside it.
Cancel while the checkout is still `INITIATED` whenever you can. A card checkout already handed off to the payment provider (`PENDING`) keeps a live session upstream, if the buyer completes it after you cancel, Suby refuses to credit the payment and the charge has to be refunded on the provider side.
## After Payment
Once a customer completes payment, they are shown a default Suby confirmation page with their order details.
Custom success pages are not supported at this time.
Endpoints, parameters, and response objects for Checkout Sessions.
# Customers
Source: https://docs.suby.fi/v3-beta/docs/features/customers
View and manage your customers from the dashboard.
Every customer who completes a purchase through Suby gets a customer record automatically. Click on any customer to open a detailed view with everything about them in one place, revenue generated, active subscriptions, payment history, and analytics, and manage their subscriptions or issue refunds directly from there.
![Customer]()
## Customer Profile
Just click on a customer to open their detailed profile, which includes:
* Total revenue generated by that customer across all your products
* Full payment history, every transaction linked to that customer
* Active subscriptions, all current active subscriptions across any of your products
* Subscription status, active, cancelled, past due
* Payment method on file
* Customer-level analytics, spending trends and activity over time
![Customer Details]()
## What You Can Do
One click on a customer surfaces everything about them, revenue, subscriptions, payments, and analytics, no need to piece it together across pages.
See every payment the customer has made, with status, amount, date, and product.
Refund any successful transaction directly from the customer profile without navigating to the Transactions page.
A customer can have multiple active subscriptions simultaneously. Cancel any individual subscription without affecting their others.
## Accessing Customers
Navigate to **Customers** in your dashboard.
Search by email or name.
Click on a customer to open their detailed profile, with their revenue, subscriptions, payments, and analytics all in one view.
## Via API
Endpoints, parameters, and response objects for Customers.
# Discord Integration
Source: https://docs.suby.fi/v3-beta/docs/features/discord-integration
Sell access, gate roles, and manage your entire payment flow inside Discord.
Suby's Discord integration connects your products directly to your server. Once configured, everything runs automatically, role gating, payments, notifications, and renewals, without leaving Discord.
## What's Included
Grant and revoke Discord roles automatically based on payment status. When a customer pays, the role is assigned instantly. When they cancel or lapse, access is revoked.
Generate a PayLink tied to a paid role and share it anywhere, inside your server, on social media, or in a bio link.
Run the full checkout flow inside Discord. Customers pay with cards or stablecoins without ever leaving the server.
Payment confirmations, renewal reminders, and cancellation notices sent directly inside Discord.
Offer a free access period before billing starts, configured natively inside the flow.
Server owners manage payments, members, and notifications directly from Discord using built-in slash commands.
## How It Works
**For your members**
A member clicks your PayLink or triggers checkout inside Discord.
![Checkoutdiscord]( "Checkoutdiscord")
They complete payment with a card or stablecoin/crypto
![Checkout 2]()
![Crypto]( "Crypto")
The paid role is granted instantly and they receive a confirmation inside Discord.
![Ne]( "Ne")
On renewal, nothing changes, access is maintained automatically.
![Renew]( "Renew")
On cancellation or failed payment, the role is revoked and they are notified.
![Cancel]( "Cancel")
**For you as the server owner**
Manage everything from your Suby dashboard or directly via slash commands inside Discord.
Receive notifications for new payments, renewals, and cancellations.
Grant or revoke access manually from the dashboard at any time.
## Setting Up the Integration
Setting up Discord starts at the product level. You create a product in Suby and connect it to a server and a paid role in the same flow.
Go to your dashboard and click **Create product**. Set your billing type, price, and currency.
Under **Integration**, select **Discord**.
Authorize Suby on your Discord server when prompted.
Choose the role you want to grant on payment.
Suby generates a PayLink and activates native checkout for that role.
You can connect multiple servers and map multiple products to different roles across the same server or different ones.
***
Step-by-step setup, slash commands, notifications, free days, and native checkout.
# Discount Codes
Source: https://docs.suby.fi/v3-beta/docs/features/discount-codes
Create fixed or percentage discounts with usage limits and expiry dates.
Discount codes let you offer reductions at checkout, for promotions, launches, or specific customer segments. Customers enter the code at checkout and the price adjusts automatically.
![Discounts]()
## How It Works
Set up a discount code in your dashboard with a type, value, target products, and optional limits.
Send the code to customers via email, Discord, social media, or anywhere else.
The customer enters the code at checkout.
Suby adjusts the amount charged automatically.
## Creating a Discount Code
Navigate to \*\*Catalog → Discount \*\*in your dashboard and click **New discount**.
Set the code string (e.g. `LAUNCH50`), and choose your discount type: **percentage** (e.g. 20% off) or **fixed amount** (e.g. \$10 off).
Apply the code to **one product**, **several specific products**, or **all products**.
* **Usage limit**: cap the total number of times the code can be used, across all customers, not per user.
* **Pre-applied at checkout**: automatically apply the discount without the customer having to enter the code.
* **Expiry date**: set a date after which the code stops working.
Your code is active immediately.
## Discount Types
| Type | Example |
| - | - |
| Percentage | 20% off the checkout total |
| Fixed amount | \$10 off the checkout total |
## Limitations
Discount codes apply to the checkout total after tax calculation. Codes are case-insensitive at checkout. A usage limit of 1 makes a code single-use, and that limit is shared across all customers, not reset per customer.
## Via API
You can also create discount codes programmatically with `POST /api/discount/create` — set a `PERCENT` or `FIXED` type, target `"all"` products or a specific list, and optionally cap usage (`maxUses`) or set an expiry (`expiresAt`).
Codes can be applied two ways:
* **Customer enters it at checkout** — the price adjusts automatically.
* **Pre-applied by you** — pass the code in the `discountCode` field on `POST /api/payment/create` or `POST /api/subscription/create`, and it's applied to the checkout without the customer typing anything. It's silently ignored if the code is invalid, expired, exhausted, or not attached to that product.
### Per-account codes (`externalRef`)
Set `externalRef` when creating a code to **bind it to a single account**. It is then only accepted on a checkout created with the **exact same** `externalRef`, and refused everywhere else with `DISCOUNT_CODE_EXTERNAL_REF_MISMATCH`.
Use it for codes that must not be transferable between your users — prepaid credits, upgrade proration, one-off goodwill gestures. Matching is exact (no case folding, no trimming), and a checkout created without an `externalRef` can never redeem a bound code. Omit the field for a code any customer can use.
# Fraud Prevention System
Source: https://docs.suby.fi/v3-beta/docs/features/fraud-system
How Suby protects against automated attacks, card testing, and suspicious payment activity.
Suby's fraud prevention system protects against automated attacks, card testing, and suspicious payment activity. It combines bot detection, card testing prevention, and device fingerprinting, three independent layers that work together at the point of payment.
## Protection layers
Behavioral analysis and challenge-response to detect and block automated traffic.
Detects rapid sequential payment attempts characteristic of stolen card validation.
Persistent device identity tracking to link activity across sessions and accounts.
## Anti-bot detection
The anti-bot layer analyses dozens of passive signals during the payment session, mouse movement entropy, keystroke timing, browser environment consistency, and TLS fingerprint, to produce a bot confidence score for each checkout attempt.
Cloudflare CAPTCHA is used as an additional layer of protection when the confidence score crosses a defined threshold.
## Anti-card testing
Card testing attacks involve running large numbers of stolen card numbers against a payment endpoint to identify valid ones. Suby detects this pattern through velocity checks on both the user account and the device fingerprint, regardless of whether a new guest session is opened.
Detection rules:
```yaml theme={null}
card_testing:
max_declined_attempts: 3 # within rolling window
velocity_window_seconds: 300 # 5-minute window
distinct_cards_threshold: 3 # unique PANs per session
small_amount_probe_limit: 2 # ≤ $1 micro-auth attempts
block_duration_hours: 24 # first offence
repeat_offence_action: "permanent"
```
Detections are keyed on a composite of device fingerprint ID, IP subnet (/24), and account ID when authenticated. All three keys are checked independently, a match on any single key is sufficient to trigger a block.
## Device fingerprinting
Every checkout session generates a stable device fingerprint that persists across browser sessions, private and incognito mode, and VPN changes. This fingerprint is the primary identity used when evaluating fraud signals and enforcing blocks.
Fingerprints are stored server-side only. They are never exposed to client-side JavaScript and cannot be queried or tampered with by the user.
## Block escalation
When a fraud signal is triggered, the system applies a progressive block policy keyed to the device fingerprint. The escalation is automatic and requires no manual intervention.
| Condition | Action | Duration | Reversible |
| - | - | - | - |
| First fraud signal | Payment blocked | 24 hours | Auto-lifted |
| Retry during 24h block | Permanent block | Indefinite | Manual review only |
| Permanent block + attempt | Silent reject + alert | Indefinite | No |
| Card testing velocity | Payment blocked | 24 hours | Auto-lifted |
# One-time Payments
Source: https://docs.suby.fi/v3-beta/docs/features/one-time-payments
Sell anything once. Digital products, services, or access, collected instantly.
One-time payments let you charge a customer a single fixed amount. No recurring billing, no subscription logic. The customer pays, gets access, and that's it.
![Onetime]()
## How It Works
When a customer completes a one-time checkout, Suby:
The payment is collected across the customer's chosen method, card, bank, Apple Pay, Google Pay, or stablecoin.
Applicable taxes are calculated and collected automatically based on the customer's location.
Access is granted based on your configured integration, PayLink, API, Discord, or Telegram.
A `payment.succeeded` event is sent to your server if you have a webhook configured.
## Use Cases
Templates, ebooks, files, and downloadable assets.
One-time service engagements or client deliverables.
Tools, communities, or platforms with a one-time entry fee.
Client payments for project-based work.
## Setting Up a One-time Payment
In your dashboard, navigate to **Catalog**, then **Product**, and click **New product**.
Enter your **product name**, **image**, **description**, **price**, and **currency**.
Choose how access is delivered once payment is completed: **Discord**, **Telegram**, **digital files**, **license key**, or **external link**.
* Apply a **discount code**
* Choose which **payment methods** are available for this specific product
* Add **custom fields** to collect information from the customer at checkout
* Set a **success URL** and **cancel URL** to redirect the customer after checkout
Your checkout is live instantly.
## Via API
Endpoints, parameters, and response objects for Checkout Sessions.
# Pay As You Go
Source: https://docs.suby.fi/v3-beta/docs/features/pay-as-you-go
Charge customers based on usage. Suby meters consumption and bills automatically.
Pay As You Go lets you charge customers based on how much they use, instead of a fixed one-time or recurring price. Suby meters usage and bills the customer accordingly.
![Pay As You Go]()
## How It Works
When a customer is on a Pay As You Go plan, Suby:
Usage is reported to Suby as your customer consumes your product or service.
At the end of the billing period, the charge is calculated based on recorded usage and your pricing.
The payment is collected across the customer's chosen method, card, bank, Apple Pay, Google Pay, or stablecoin.
Applicable taxes are calculated and collected automatically based on the customer's location.
A `payment.succeeded` event is sent to your server if you have a webhook configured.
## Use Cases
Charge per API call, per request, or per unit of compute.
Bill based on tokens processed, generations, or credits consumed.
Charge based on data processed, stored, or transferred.
Bill customers based on seats, actions, or any other usage metric specific to your product.
## Setting Up Pay As You Go
You create the product itself from the dashboard, but the usage-based configuration, defining what's metered and how usage is reported, is done via the API.
In your dashboard, navigate to **Catalog**, then **Product**, and click **New product**.
Enter your **product name**, **image**, **description**, **currency**, and select **Pay As You Go** as the billing type.
Choose how access is delivered once payment is completed: **Discord**, **Telegram**, **digital files**, **license key**, or **external link**.
* Choose which **payment methods** are available for this specific product
* Add **custom fields** to collect information from the customer at checkout
* Set a **success URL** and **cancel URL** to redirect the customer after checkout
Once the product exists, define your usage metering and pricing, and report usage events, through the API.
## Via API
Endpoints, parameters, and response objects for usage-based billing.
# PayLinks
Source: https://docs.suby.fi/v3-beta/docs/features/paylinks
A shareable checkout URL tied to a product. No code required.
A PayLink is a hosted checkout page Suby generates for your product. Share the URL, the customer pays, and Suby handles everything else, tax calculation, payment processing, and access delivery.
![Checkout 1]()
## How It Works
Set up your product in the dashboard, one-time or recurring.
Suby generates a unique hosted checkout URL for that product.
Post it on your website, bio link, Discord, email, or anywhere else.
The customer lands on a Suby-hosted checkout page and completes payment.
Access is granted automatically based on your configured integration.
## Generating a PayLink
Go to your dashboard and open the product.
Click **Generate PayLink**.
Copy the URL and share it anywhere.
## What PayLinks Support
Works for both billing types out of the box.
Cards, bank accounts, Apple Pay, Google Pay, and stablecoins.
Tax is calculated and collected in real time based on the customer's location.
Customers can apply discount codes directly at checkout.
## Limitations
PayLinks cannot be set to expire, and customer details cannot be pre-filled via the URL. For pre-filled sessions or dynamic parameters, use the [Checkout Sessions API](/v3-beta/api-reference/overview) instead.
## Combining PayLinks with the API
PayLinks and the API are not mutually exclusive. A common pattern is to use PayLinks for quick sales or marketing campaigns while using the API for subscription management, access control, and backend sync.
Endpoints, parameters, and response objects.
# Refunds
Source: https://docs.suby.fi/v3-beta/docs/features/refund
How to issue refunds from your dashboard.
Refunds can be issued directly from your dashboard on any successful payment. There is no time limit, you can refund a transaction at any point after it was processed.
Both **full** and **partial** refunds are supported. You can refund a smaller amount than the original charge, and repeat partial refunds on the same payment until the full captured amount has been returned.
Refunds apply to **card (fiat) payments** only. Crypto payments settle directly on-chain and cannot be refunded from Suby.
## How to Issue a Refund
Navigate to **Transactions** in your dashboard.
Locate the transaction with status `Completed` that you want to refund.
Click on it. A panel opens on the right with the full transaction details.
At the bottom right of the panel, click **Refund** and confirm. The refund is processed immediately.
![Refund]()
## What Happens After a Refund
The customer receives their money back via the original payment method.
The transaction status updates to `Refunded` in your dashboard.
If the refund is on a subscription payment, the subscription is cancelled and access is revoked.
The refunded amount is deducted from your next payout.
## Partial Refunds
You can refund only part of a payment by specifying an amount instead of refunding the full charge.
* Refund any amount up to the captured total, in the payment's currency.
* Call the refund repeatedly, as long as the cumulative refunded amount stays within the captured total.
* While a residual amount remains, the payment status is **`PARTIALLY_REFUNDED`**. Once the cumulative refunds reach the full captured amount, it flips to **`REFUNDED`**.
* The running total is exposed as `refundedAmountCents` on the payment, and each API call returns the `remainingRefundableCents` still available.
A **subscription** payment is cancelled and access revoked only when it is **fully** refunded. A partial refund on a subscription payment leaves access intact.
## Webhooks
Refunds emit signed payment webhooks so your systems stay in sync:
| Event | When |
| - | - |
| `PARTIAL_REFUNDED` | A partial refund was issued and a residual amount still remains. `data.payment.refundedAmountCents` carries the cumulative total. |
| `PAYMENT_REFUNDED` | The payment was fully refunded (a plain full refund, or the partial refund that completes the captured total). |
## Via API
Endpoints, parameters, and response objects for Refunds, including the optional `amountInCents` for partial refunds.
# Subscriptions
Source: https://docs.suby.fi/v3-beta/docs/features/subscriptions
Charge customers on a recurring basis. Suby handles renewals, failed payment recovery, and cancellations automatically.
Subscriptions let you charge customers on a recurring basis. Suby handles the full lifecycle, renewals, failed payment recovery, and cancellations, automatically.
![Subscription 1]()
## How It Works
When a customer subscribes, Suby:
The first charge is collected immediately at checkout across the customer's chosen method, card, bank, Apple Pay, Google Pay, or stablecoin.
Applicable taxes are calculated and collected automatically based on the customer's location.
Access is granted based on your configured integration, PayLink, API, Discord, or Telegram.
The subscription renews at the end of each billing cycle. Failed payments trigger dunning automatically.
A `subscription.created` event is sent to your server if you have a webhook configured.
## Use Cases
Monthly or yearly access to software, APIs, or developer tools.
Recurring access to paid Discord roles and private channels.
Subscription-gated Telegram groups and channels.
Paid newsletters, content libraries, and creator memberships.
## Billing Cycles
Suby supports any billing cycle, weekly, monthly, every 3 months, every 6 months, or yearly. You set it when creating your product.
## Dunning
Access never lasts longer than the period that was paid for. If a card renewal is declined, access is revoked right away and Suby retries the charge over the next 3 days, notifying the customer to update their payment method. If a retry succeeds, access comes back automatically; if none does, the subscription ends.
Crypto subscribers are reminded 48 hours before the due date (24 hours for plans shorter than a month). Without payment by the due date, access is revoked; the subscriber still has 2 days to renew the same subscription and get their access back.
## Setting Up a Subscription
Setup works the same way as [one-time payments](/v3-beta/docs/features/subscriptions), with one difference: you also select a **billing interval**.
In your dashboard, navigate to **Catalog**, then **Product**, and click **New product**.
Enter your **product name**, **image**, **description**, **price**, **currency**, and select the **billing interval** (weekly, monthly, yearly).
Choose how access is delivered once payment is completed: **Discord**, **Telegram**, **digital files**, **license key**, or **external link**.
* Apply a **discount code**
* Choose which **payment methods** are available for this specific product
* Add **custom fields** to collect information from the customer at checkout
* Set a **success URL** and **cancel URL** to redirect the customer after checkout
Your subscription is live instantly.
## Via API
Endpoints, parameters, and response objects for Checkout Sessions.
# Global Tax & Compliance
Source: https://docs.suby.fi/v3-beta/docs/features/tax-compliance
VAT, GST, and sales tax across 190+ countries, handled automatically in MoR mode.
Whether tax is handled for you or falls on you depends on which mode your account runs on.
Suby is your Merchant of Record and takes on the full legal and tax liability for every transaction. You never register for foreign tax IDs, file returns, or deal with tax authorities.
You remain the seller of record. You are responsible for calculating, collecting, declaring, and remitting sales tax, VAT, and GST yourself, worldwide.
Mode assignment is handled by Suby during onboarding, based on your business profile, see [Review Process](/v3-beta/docs/merchants/account-review-process). If you'd like your account to run on **MoR mode** specifically, let the support team know when you apply.
## What Suby Handles (MoR mode only)
Real-time tax rates applied at checkout based on the customer's location.
Included in the checkout price shown to the customer.
Suby files and pays taxes to the relevant authorities on your behalf.
We stay current with changing regulations across all supported jurisdictions.
None of the above applies in **PayFac mode**. If you're on PayFac, tax calculation, collection, and remittance are entirely your own responsibility, see [Taxes & VAT Handling (PayFac)](/v3-beta/docs/merchants/taxes-vat-payfac).
## Supported Taxes (MoR mode)
| Tax type | Coverage |
| - | - |
| VAT (Value Added Tax) | European Union, UK, and other VAT jurisdictions |
| GST (Goods and Services Tax) | Australia, Canada, India, New Zealand, and others |
| Sales tax | United States (state and local) |
| Digital services taxes | All applicable jurisdictions globally |
## What This Means for You
No foreign tax registration required. No tax returns to file. No exposure to tax liability in markets where you sell. Your revenue is net of taxes, Suby handles the gross amount.
You register, calculate, collect, and remit tax yourself in every jurisdiction where you're liable to. Suby does not handle any part of this for you.
## Learn More
Learn how the MoR model works and what it means for your business.
Learn how the PayFac model works and what it means for your business.
Technical details, B2B reverse charge, US nexus, and FAQ.
What you need to set up yourself if you're on PayFac.
# Telegram Integration
Source: https://docs.suby.fi/v3-beta/docs/features/telegram-integration
Sell access to Telegram groups and channels with a native checkout experience.
Suby's Telegram integration lets you monetize Telegram groups and channels without managing access manually. Configure everything when you create your PayLink, Suby handles the rest.
## What's Included
Generate a PayLink tied to a Telegram group or channel and share it anywhere. Customers pay and receive an invite link instantly.
Run the full checkout flow inside Telegram. Customers pay with cards or stablecoins without leaving the app.
Payment confirmations, renewal reminders, and cancellation notices sent directly inside Telegram.
## How It Works
**For your members**
A member clicks your PayLink or triggers checkout inside Telegram.
![Checkout 3]()
![Checkouttelegr]()
They complete payment with a card or stablecoin.
They receive an invite link instantly.
![Captured’écran2026 03 13à10 55 35]()
On renewal, access is maintained automatically.
On cancellation or failed payment, they are removed and notified.
**For you**
Everything is set up at PayLink creation, no ongoing manual work.
Receive notifications for new payments, renewals, and cancellations.
![Paymenttg]()
Manage access manually from your dashboard at any time.
## Setting Up the Integration
Telegram is configured directly when you create a PayLink. There is no separate setup step.
Go to your dashboard and click **Create product**. Set your billing type, price, and currency.
Under **Integration**, select **Telegram**.
Add the Suby bot to your group or channel and grant it admin permissions when prompted.
Choose the Telegram group or channel you want to gate.
Your PayLink is ready to share.
Telegram integration supports groups and channels only.
***
Step-by-step setup, native checkout, and notification configuration.
# Transactions
Source: https://docs.suby.fi/v3-beta/docs/features/transactions
The complete log of every payment event across your account.
The Transactions page is the full log of every payment event on your account, every charge attempt, regardless of outcome. Unlike the Payments page which shows successful payments only, Transactions shows the complete picture.
![Transactions]()
## Transaction Statuses
| Status | What it means |
| - | - |
| `Completed` | Payment was processed successfully |
| `Incomplete` | The customer did not finish the payment (checkout abandoned or left pending on their end) |
| `Failed` | A technical error occurred while processing the payment |
| `Declined` | The customer's bank declined the payment (insufficient funds, wrong PIN, 3DS not authorized, or other bank-side reason) |
| `Refunded` | Payment was successfully refunded |
## What You Can Do
Click any transaction to see the full breakdown, amount, fees, customer, product, payment method, and timestamp.
Refund any transaction with status `Completed` directly from this page.
Narrow down by status (Completed, Incomplete, Failed, Declined, Refunded) or by date range.
Download your full transaction log as CSV for accounting, reconciliation, or tax records.
## Exporting Transactions
Navigate to **Transactions** in your dashboard.
Filter by status and period as needed.
Click **Export** and download your CSV.
The export includes all transaction details matching your current filter selection, useful for accounting, reconciliation, or tax records.
![Export]()
# Discord Bot Commands
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/bot-commands
Manage your Suby integration directly from Discord using slash commands.
The initial setup is done on [app.suby.fi](https://app.suby.fi). Once live, you can manage roles, reminders, and subscriptions directly from Discord using the following commands.
## Commands
Displays the welcome message with your current product and setup status.
Link a Discord role to a paid product. Use this to update the role associated with a product after initial setup.
Link a reminder channel so subscribers receive renewal alerts before their access expires.
Only required for crypto payments. Card payments are automatically debited.
Create a checkout channel that displays a button for your available paid products, letting members subscribe directly from Discord.
View your active products including name, Plan ID, price, billing cycle, and associated role.
Instantly grant a role to a user for a set number of days, without requiring a payment. Useful for trials, giveaways, or manual exceptions.
Get notified when a new member subscribes.
Recommended in a public channel for social proof.
Get notified when a member renews their subscription.
Recommended in a public channel for stronger community impact.
Get notified when a member cancels their subscription.
# Discord Checkout (Optional)
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/checkout
Create a Discord-native checkout channel for all your paid access links, with a built-in checkout.
The Discord Checkout is an optional step. It creates a dedicated checkout channel inside your server that displays all your paid products with a built-in checkout · subscribers pay without ever leaving Discord.
Before setting up the Discord Checkout, make sure you have completed the [Discord Integration Setup](/v3-beta/docs/guides/discord/setup).
## When to Use It
One dedicated channel with all your paid access links, no external landing page needed.
A checkout experience entirely inside Discord. No redirects, no friction.
## Setup
Open the server where the Suby bot is already installed and active.
Type `/checkout` in any channel the bot has access to. The bot will create a dedicated checkout channel inside your server.
The bot publishes your checkout inside the channel, your paid product(s) are displayed with a built-in checkout button.
![Captured’écran2026 03 13à12 17 46]()
## User Flow
Once the checkout is live, the entire experience runs inside Discord.
The user clicks the checkout button directly inside the Discord channel.
![Checkoutdiscord]( "Checkoutdiscord")
The Suby bot delivers the checkout flow natively inside Discord.
Once payment is confirmed, the paid role is assigned instantly and the user gets access to the gated channels.
Fully automated, built-in checkout, no external links, entirely native to Discord.
# Notification Setup
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/notifications
Configure renewal reminders and subscription notifications for your Discord server.
Suby sends automated notifications inside Discord to keep both you and your members informed. Use the slash commands below to configure where each notification is sent.
## Notification Commands
Links a reminder channel so subscribers receive renewal alerts before their access expires.
Only required for crypto payments. Card payments are automatically debited, no reminders needed.
Get notified when a new member subscribes.
Recommended in a public channel for social proof.
Get notified when a member renews their subscription.
Recommended in a public channel for stronger community impact.
Get notified when a member cancels their subscription.
## Default Notification Messages
Notifications are not customizable at the moment. Here is what they look like by default.
![Notification example 1]()
# Discord Overview
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/overview
Accept payments and manage paid access for your Discord server with Suby.
The Suby bot acts as an access controller for your Discord community. It grants, manages, and revokes access to private channels automatically based on payment status, no custom code required.
## How It Works
Discord access is controlled through roles. A paid role unlocks private channels, and losing that role immediately removes access. Suby automates the entire lifecycle.
Once a payment is confirmed, the Suby bot assigns the paid role instantly, even if the user is not yet a member of your server. New members are invited automatically.
Access is revoked automatically when a payment fails, a card subscription fails to renew, or a crypto subscription is not renewed after the reminder period.
The bot notifies members of successful payments, upcoming renewal reminders (crypto subscriptions), and access removal, reducing churn and confusion.
Grant temporary access to any user using the `/freedays` command. The role is assigned for a fixed period and removed automatically when it expires. Useful for trials, giveaways, or manual exceptions.
## Access Lifecycle
The customer completes payment via your PayLink or native Discord checkout.
![Newcheckout]()
![Checkoutdiscord]( "Checkoutdiscord")
The Suby bot assigns the paid role instantly. If the customer is not yet in your server, they receive an invite automatically.
![Ne]( "Ne")
Access is maintained automatically for the duration of the subscription. No manual action required.
On renewal, nothing changes, the role stays assigned and access continues uninterrupted.
![Renew]( "Renew")
The role is revoked automatically. The member is notified inside Discord.
![Remove]( "Remove")
## Renewal & Access Removal
If a card renewal is declined, the role is revoked right away and the member is notified. Suby retries the charge over the next 3 days; if a retry succeeds, the role is given back automatically.
Suby sends a renewal reminder 48 hours before the access period ends (24 hours for plans shorter than a month). If you configured a cooldown role, it is added alongside the paid role when the reminder goes out. Without payment by the end of the period, the paid role is removed; the cooldown role stays until the member pays, and paying within 2 days gives the paid role back.
![Renewal reminder]( "Renewal reminder")
You can manually revoke or grant access at any time from your Suby dashboard, independently of the subscription state.
## Free Days
Use the `/freedays` command to grant temporary access to any user without requiring a payment.
The role is assigned for a fixed number of days and removed automatically when the free period ends. Useful for trials, giveaways, or manual exceptions.
# How to Give Discord Permissions
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/permissions
Configure the Suby bot permissions on your Discord server.
The Suby bot needs specific permissions to assign roles, send notifications, and manage access. Configure them at two levels, server-wide and per channel.
## Bot Permissions
Grant the following permissions to the Suby Bot role at the server level.
Go to **Settings → Server Settings → Roles**.
Find and click on the **Suby Bot** role.
Open the **Permissions** tab and make sure the following are enabled:
* View Channels
* Send Messages
* Send Messages in Threads
* Embed Links
## Channel Permissions
To allow the bot to operate in a specific channel, configure permissions at the channel level.
Go to the channel, click **Edit Channel**, then open **Permissions**.
Go to **Advanced Permissions** and add **Suby Bot**.
Make sure the following are enabled:
* View Channels
* Send Messages
* Send Messages in Threads
* Embed Links
If the Suby bot is missing any of these permissions, it will not be able to assign or revoke roles, which will break your access gating flow.
# Discord Integration Setup
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/setup
Connect your Discord server to Suby and start gating access with paid roles in minutes.
This guide walks you through connecting your Discord server to Suby. Before starting, make sure you have already created a product and selected Discord as the integration method.
Follow the Quickstart guide to set up your first product in under 2 minutes.
## Setup
Connect your Discord account to Suby so the bot can manage roles and access automatically.
![Discord Integration1]()
Choose the Discord server you want to connect, then invite the Suby bot to your server when prompted.
Select the paid role users will receive after a successful payment, and configure a reminder channel for crypto subscribers.
![Discord Integration3]()
Make sure the Suby bot is positioned **above** the paid role in your Discord role hierarchy. If the bot's role is lower than the paid role, it will not be able to assign or revoke it.
The reminder channel is only required if you accept crypto payments. It is where Suby sends renewal reminders to members before their access period expires.
Click **Publish now**. Your PayLink is live and the bot is active.
## Updating Your Configuration
If you need to change the paid role or reminder channel after publishing, you can do it directly from Discord using Suby bot slash commands, no need to go back to the dashboard.
Full list of available commands for managing your Discord integration.
# Troubleshooting
Source: https://docs.suby.fi/v3-beta/docs/guides/discord/troubleshooting
Common setup issues and how to fix them.
If the Suby bot is not working as expected, check the following common issues.
## Common Issues
The Suby bot role must be positioned **above** all paid roles in your Discord role hierarchy. If it is lower, Discord will prevent the bot from assigning or removing those roles.
Go to **Server Settings → Roles** and drag the Suby Bot role above all roles it needs to manage.
Make sure the Suby bot has the following permissions at the server level:
* Send Messages
* Send Messages in Threads
* Embed Links
For each channel linked to Suby, make sure the bot has the following channel-level permissions:
* View Channel
* Send Messages
* View Message History
* Embed Links
Step-by-step guide to configuring bot permissions at server and channel level.
Only server Admins can run Suby bot commands. Make sure you have the Admin role on the server before running any slash command.
If the bot is active but not assigning roles after payment, the role may not be linked to your product. Run `/setuprole` in your server to link a role to a paid product.
If you are still experiencing issues after checking the above, reach out via [Suby support](https://www.suby.fi/support).
# Telegram Checkout (Optional)
Source: https://docs.suby.fi/v3-beta/docs/guides/telegram/checkout
Create a Telegram-native entry point for all your paid access links, with a built-in checkout.
The Telegram Checkout is an optional step. It creates a single public Telegram channel that displays all your paid products with a built-in checkout, subscribers pay without ever leaving Telegram.
Before setting up the Telegram Checkout, make sure you have completed the [Telegram Integration Setup](/v3-beta/docs/guides/telegram/setup).
## When to Use It
One public place with all your paid access links, no external landing page needed.
A checkout experience entirely inside Telegram. No redirects, no friction.
## Setup
Create a new Telegram channel and set it to **public**. Make sure members are not allowed to post, this channel is display-only.
![Telegram Checkout 1]()
Open the Suby bot and select the public channel you just created.
![Telegram Checkout 2]()
The bot publishes your checkout inside the channel, your paid product(s) are displayed with a built-in checkout button.
![Telegram Checkout 3]()
![Telegram Checkout 4]()
## User Flow
Once the checkout is live, the entire experience runs inside Telegram.
The user clicks **Pay for \[your product]** directly inside the public channel.
The user clicks Start in the Suby bot. The built-in checkout is delivered automatically.
Once payment is confirmed, the bot sends the private community access link directly to the user.
Fully automated, built-in checkout, no external links, entirely native to Telegram.
# Telegram Overview
Source: https://docs.suby.fi/v3-beta/docs/guides/telegram/overview
Accept payments and manage paid access for your Telegram groups and channels with Suby.
The Suby bot manages paid access to private Telegram groups and channels automatically. It controls who can join, stay, or get removed based on subscription status, no manual work required.
## How It Works
Once a payment is confirmed, the Suby bot adds the user to your private group or channel instantly, even if they were not previously a member.
Access is revoked automatically as soon as a renewal is not paid on its due date · a declined card, or a crypto subscription not renewed. The user is removed without any manual action, and sent a new invite link if a later payment succeeds.
Card subscriptions renew automatically, no action needed from the subscriber. Crypto subscribers receive a reminder before their access expires and must renew manually.
For crypto subscriptions, Suby sends a renewal reminder directly inside Telegram 48 hours before access expires (24 hours for plans shorter than a month). If the payment is completed before the due date, access continues uninterrupted.
## Access Lifecycle
The customer completes payment via your PayLink or native Telegram checkout.
![Newqrcodecheckout]()
![Checkouttelegr]()
The Suby bot adds the user to your private group or channel instantly.
![Captured’écran2026 03 13à10 55 35]()
Access is maintained automatically for the duration of the subscription.
Card subscriptions renew silently. Crypto subscribers receive a reminder and must complete payment to keep their subscription active.
# Telegram Integration Setup
Source: https://docs.suby.fi/v3-beta/docs/guides/telegram/setup
Connect your Telegram group or channel to Suby and start gating access in minutes.
This guide walks you through connecting your Telegram group or channel to Suby. The setup happens between the Suby dashboard and the Suby Telegram bot, follow the steps in order.
Follow the Quickstart guide to set up your first product in under 2 minutes.
## Setup
Open the Suby Telegram bot and follow the linking flow. This connects your Telegram account to your Suby dashboard.
Once the linking is complete, come back to the platform to continue.
![Telegramdash]()
Once your Telegram account is linked, publish your product from the Suby dashboard.
Publishing is required before the bot can activate the product. The bot cannot gate access to an unpublished product.
Go back to the Suby Telegram bot and type **/start**. Follow the steps displayed by the bot.
Click **Create Paid Access**.
![Telegram Integration6]()
Add the Suby bot to the private group or channel you want to gate, and grant it the required admin permissions.
![Telegram Integration7]()
Without the correct permissions, the bot will not be able to manage member entry and removal. Make sure to grant admin rights before continuing.
Once the bot is added, go back to the bot and type **/setup**. Select the product you want to associate with your gated group or channel.
![Telegram Integration8]()
![Telegram Integration9]()
Run /setup only after the bot has been added to the group or channel. Running it before will not work.
## You're Live
Once the link between Suby and your private community is complete, you have two options to share access:
Share your PayLink directly with your audience. Customers pay and receive access instantly.
Create a public-facing checkout page for your Telegram community.
# Compliance
Source: https://docs.suby.fi/v3-beta/docs/legal/compliance
Suby operates as a non-custodial payment orchestration layer, relying on licensed third-party partners to ensure regulatory compliance across fiat and crypto payment flows.
Suby is a technology company providing a payment orchestration layer for recurring and one-off payments. All regulated activities are handled by licensed third-party partners, Suby does not act as a bank, money transmitter, or custodian.
## Suby's Role
Suby provides technical infrastructure to configure, trigger, and monitor payment instructions. It does not hold or custody customer funds, fiat balances, private keys, or card data at any point.
All payments are executed and settled by licensed third-party providers or blockchain networks, directly between end users and merchants. Funds do not transit through accounts owned or operated by Suby.
Suby does not have discretionary authority over funds and does not independently determine beneficiaries or settlement destinations outside of merchant-defined configurations.
## Licensed Partners
All regulated activities within the payment stack are handled by licensed and compliant third-party partners.
Handle card payment execution, settlement, and PCI DSS compliance.
Responsible for fiat settlement, funds custody, and regulatory reporting.
Handle fiat-to-crypto and crypto-to-fiat conversion flows.
Responsible for on-chain execution, stablecoin issuance, and network compliance.
These partners are responsible for AML/CTF compliance, sanctions screening, regulatory reporting, and licensing. Suby integrates with them via APIs and does not perform regulated financial activities itself.
## Payment Flow
For both card and crypto payments:
* Payments are executed and settled by licensed PSPs or blockchain networks
* Funds are settled directly to merchant-designated wallets or accounts
* Suby acts as a technical orchestration layer, triggering, routing, and monitoring payment instructions
* Payment flows and automated actions are enforced through predefined rules and partner-level controls
## Merchant Onboarding & Verification
Suby performs identity and business verification on all merchants during onboarding, before card payments are enabled.
Applied to individual merchants, identity verification of the person behind the account, including government-issued ID and proof of address.
Applied to business merchants, verification of the legal entity, beneficial ownership, and business activity.
Merchant approvals are subject to two layers of review:
* Suby's internal KYC/KYB assessment
* Approval by Suby's licensed PSP and banking partners, who apply their own compliance and risk frameworks
A merchant approved by Suby may still be subject to additional review or restrictions imposed by our regulated partners. Final approval for card payment processing depends on partner-level clearance.
## Card Payments & PCI Compliance
Card payments are processed exclusively via PCI DSS-compliant payment providers.
Suby servers never receive, store, or process raw cardholder data. Card information is transmitted directly from the end user to the PSP via tokenization and provider-hosted payment flows.
Disputes, chargebacks, and refunds follow card-network-compliant procedures, including evidence management, SLA handling, and refund orchestration through the PSP.
## End-User Identity & KYC
End-user KYC is not applied, in line with standard card-network rules and PSP risk frameworks.
May be available without end-user identity checks, subject to partner requirements, transaction thresholds, and jurisdictional regulations. Where required, identity verification is performed by Suby's regulated partners.
## Data Protection
Sensitive payment data is never stored on Suby systems.
User and merchant data is processed strictly for service delivery and platform operations. Suby does not sell, rent, or monetize personal data.
## Jurisdictional Limitations
Suby does not actively market or provide services in jurisdictions where its partners are unable to offer compliant payment services. Feature availability may vary based on merchant location, end-user location, payment method, and partner coverage.
View the full list of supported regions and restricted jurisdictions.
# Privacy Policy
Source: https://docs.suby.fi/v3-beta/docs/legal/privacy-policy
Last updated: September 10, 2026
UNDER EU REGULATION 2016/679 OF APRIL 27, 2016 (GDPR)\
AND FRENCH LAW N°78-17 OF JANUARY 6, 1978
### **PREAMBLE**
This Privacy Policy (hereinafter referred to as the “Privacy Policy”) shall be effective as of September 10, 2026.
The Privacy Policy’s primary objective is to provide Users with comprehensive information regarding the processing of their personal data by **Suby** during their utilization of the Services, when placing orders related to the Services, or more generally when accessing the website accessible at [**https://suby.fi**](https://suby.fi) (hereinafter referred to as the “Website” or the “Site”).
This Privacy Policy constitutes an integral component of the Terms and Conditions (hereinafter referred to as the “T\&Cs”).
All terms not defined herein have the meaning given to them in the T\&Cs.
**Suby** is a simplified joint-stock company with a capital of 1000 euros, having its registered office at **BUREAU 326, 59 RUE DE PONTHIEU, 75008 PARIS (FRANCE)**, registered under **SIREN 990739302** (hereinafter the “Company”).
Its email address is: [**contact@suby.fi**](mailto:contact@suby.fi).
The use of the Site, any application or software provided by the Company, or any Service offered on it by any User constitutes full acceptance by the User of these terms. Consequently, any User who does not wish to consent to these terms is free to refrain from visiting or using the Site, the Application, or the Services.
***
### **1. PERSONAL DATA SUBJECT TO COLLECTION**
#### **1.1. DATA PROVIDED BY THE USER**
The categories of personal data collected are as follows:
1. **Identification Data**: name, first name;
2. **Contact Data**: email address, social media identifiers ;
3. **Service-Related Data**: login credentials, invoices, purchase history, purpose of payment, interactions on the Services, communications with customer support ;
4. **Financial Information**: card details, identifiers enabling the use of third-party payment services (e.g., Visa, Mastercard, PayPal, Apple Pay, Google Pay) ;
5. **Non-Custodial Wallet Credentials**: public wallet addresses, identifiers and transaction records ;
6. **Information Regarding Third Parties**: data relating to third parties receiving payments through the Services, provided the User has obtained their consent ;
7. **Commercial and/or Identification Information**: additional information required for high-value transactions or compliance with AML obligations.
***
#### **1.2. INFORMATION COLLECTED ABOUT USERS**
1. Transaction Data : Details of the transactions executed when utilizing the Services, including the geographical location from which the transaction originates ;
2. Technical Data : Internet Protocol (« IP ») address used to connect the device to the Internet, login credentials, browser type and version, time zone setting, browser plug-in types and versions, and operating system and platform ;
3. Visit Data : Information regarding the visit, including the full Uniform Resource Locators (« URL ») clickstream to, through, and from the Website or App (including date and time); products viewed or searched for; page response times, download errors, duration of visits to specific pages, page interaction details (such as scrolling, clicks, and mouse-overs), methods used to navigate away from the page, and any telephone number used to contact Customer Support.
***
#### **1.3. INFORMATION FROM OTHER SOURCES**
Personal data about users may also be collected through any subsidiary or affiliated company, or any other party, including third parties, as listed below :
1. Social Media Data : Any data accessible on the user's social networks when the user grants the Site permission to access their data on a social network ;
2. Geolocation Data : Any data transmitted by a geolocation service provider to personalize the provision of the Services based on the user's location, provided the user agrees to share their location ;
3. Partner Data : Any data transmitted by a partner company or business in the context of providing a Service ;
4. Public and Supplier Data : Any data accessible publicly and/or from data suppliers, allowing validation or completion of the information being processed ;
5. Blockchain information : any data readily available on public blockchains.
***
#### **1.4. INFORMATION COLLECTED DURING THE USE OF THE SITE OR SERVICES**
During the use of the Site or Services, particularly for audience measurement and/or targeted advertising purposes, the following data and information may be automatically collected using cookies, trackers, or any other equivalent technical means :
1. Connection Information : Computer model, connection environment, IP address, type and version of the internet browser, version of the operating system, other software installed in the environment, version of the mobile platform, technical identifiers, error reports and execution data, geolocation (region, city, or village) ;
2. Usage Data : Features used, settings selected, data viewed, times and dates of consultation, search terms, pages visited and searched by the User.
Please note that cookies are text files which may be read by a web server from the domain of the Website or the App and are placed directly on the User's hard drive or SSD. These files can be utilized to store User preferences and settings, facilitate login processes on the Site, and enable the use of the Services. Additionally, cookies allow for targeted advertising and the analysis of operations performed on the Site. Users have the ability to control cookies through their browser preferences and other tools. However, blocking certain cookies may result in a diminished user experience on the Site and/or restricted access to the Services.
***
### **2. CONTACT**
#### **2.1. DATA CONTROLLER**
The data controller is the Company:
**Suby** a French simplified joint-stock company with a share capital of 1000 euros\
**BUREAU 326, 59 RUE DE PONTHIEU**\
**75008 PARIS – FRANCE**\
**SIREN: 990739302**\
NAF / APE Code 6201Z
Its email address is: [**contact@suby.fi**](mailto:contact@suby.fi).
***
#### **2.2. DATA PROTECTION OFFICER**
The Data Protection Officer is **Mr. Gaspard Lézin**.
Requests from Users concerning personal data can be sent to the following email address:\
[**gaspard@suby.fi**](mailto:gaspard@suby.fi)
or by post to the attention of:
**Mr. Gaspard Lézin**\
**Suby**\
BUREAU 326, 59 RUE DE PONTHIEU\
75008 PARIS – FRANCE
***
### **3. COMPLAINT TO THE CNIL**
Users may lodge a complaint with the CNIL:\
CNIL – 3 Place de Fontenoy – TSA 80715 – 75334 PARIS 07 – FRANCE.
***
### **4. PURPOSES OF PROCESSING PERSONAL DATA**
The purposes of processing Users' personal data are as follows:
1. Contractual obligations : To carry out obligations related to the contract with the Company and to provide Users with information, products, and services ;
2. User account creation : Registration, identifiers, and passwords ;
3. User account management : Activation and management of access to the Site and the User's profile, management of subscriptions, sending information about offers, updates, sending commercial proposals, offering personalized content, organizing events ;
4. Notifications : To notify Users about changes to the Services ;
5. Customization : To customize the Services and the information provided to Users, addressing their needs based on factors such as country of address and transaction history. For example, if Users frequently send funds from one particular currency or token to another, this information may be used to inform Users of new product updates or features ;
6. Advertising : Providing targeted advertising, promotional messages, invitations to participate in surveys or lotteries, notifications, and other information related to the Services and Users’ interests, offering specific content based on the User’s location, and more generally to deliver relevant advertising to Users ;
7. Use of Services : To process requests, orders, downloads, subscriptions to services, billing, payment, and execution of transactions or contracts ;
8. Provision of technical support : Ensuring the proper functioning and security of the Site and Services, technical support, customer service for Services and products ;
9. Improvement and development : Improvement of Services and products and creation of new products and services, identifying usage trends, data analysis, auditing, research, reporting, determining the effectiveness of promotional campaigns, and evaluating commercial performance ;
10. Safety and security : As part of efforts to keep the Services safe and secure ;
11. Administration and internal operations : Administering the Services and for internal operations, including troubleshooting, data analysis, testing, research, statistical and survey purposes ;
12. Effectiveness measurement : To measure or understand the effectiveness of advertising served ;
13. Interactive Features : Allowing participation in interactive features of the Services, when chosen by the User ;
14. Third-party information : Providing Users, or permitting selected third parties to provide, with information about goods or services that may be of interest ;
15. Combining information : Combining information received from other sources with the information provided by Users and information collected about Users, using the combined information for the purposes set out above, depending on the types of information received ;
16. Financial and insurance : To assess financial and insurance risks, and to protect operations and those of any affiliates or partners, to recover debt or in relation to insolvency ;
17. Compliance with legal obligations under GDPR : Compliance with obligations arising from Articles 15 and following of Regulation EU 2016/679 of April 27, 2016 (GDPR), including legal compliance, resolution of potential disputes, fulfillment of contractual commitments, fraud prevention, and execution of tasks in the public interest.
18. Remedies and enforcement : To allow the pursuit of available remedies or limiting the damages that may be sustained and enforcing terms and conditions ;
19. Fraud and crime prevention : To assist in conducting or cooperating in investigations of fraud or other illegal activity where it is reasonable and appropriate to do so, to prevent and detect fraud or crime.
20. Legal and regulatory compliance : To comply with any applicable legal and/or regulatory requirements, including laws outside of the user's country of residence or to comply with any legal process, or to enforce or apply any applicable agreement, or to protect the rights, property, or safety of the Company, customers, or others, and in response to a subpoena, warrant, court order, or as otherwise required by law.
21. Discord Bot Usage: When users interact with the Suby Discord bot, limited Discord-related data may be processed in order to provide the service, including role management, subscription validation, and user migration between bots.\
\
As part of a one-time migration process, the bot may read the timestamp of specific system-generated messages in Discord channels strictly for the purpose of reconstructing subscription start and expiration dates.\
\
Suby does not read private messages, does not analyze general user conversations, and does not store message content beyond what is strictly necessary to provide the service.
In the event that personal data is processed for purposes other than those identified in this article, the data controller designated in Article 2.1 above will inform the concerned Users of this new purpose.
***
### **5. LEGAL BASES FOR PROCESSING**
The legal basis for processing personal data depends on the purpose for which the data is processed, as follows:
Performance of a contract (Article 6(1)(b) GDPR): account creation and management, use of Services, billing, payment, execution of transactions, customer support, notifications about the Services; Legal obligation (Article 6(1)(c) GDPR): compliance with AML/KYC obligations, tax and accounting record-keeping, responses to legal process, fraud and crime prevention where mandated by law; Legitimate interest (Article 6(1)(f) GDPR): safety and security of the Site and Services, administration and internal operations, improvement and development of Services, financial and insurance risk assessment, debt recovery, pursuit or defense of legal claims. Where processing relies on legitimate interest, the Company has assessed that such interest is not overridden by the User's rights and freedoms; Consent (Article 6(1)(a) GDPR): targeted advertising, marketing communications, cookies and trackers not strictly necessary for the Services, geolocation-based personalization, social media data access, Discord bot features requiring optional data access.
The User is informed that within the framework of any contractual relationship they wish to establish with the Company, their refusal to provide the requested personal data may prevent access to the Services and proper execution of the contract, where such data is necessary for that purpose.
***
### **6. DATA DESTINATION**
#### **6.1. THIRD-PARTY APPLICATIONS AND APIS**
User access to a third-party application available on the Site, the App, or a Service, as well as the use of APIs through the Website or the App, may result in the sharing of personal data concerning the User with the publisher of this third-party application or API. This sharing is primarily for the purpose of granting the User access to the application or API, subject to the terms, license agreements, and privacy policy of the third-party application or API.
#### **6.2. COMPANY AND SERVICE PROVIDERS**
Personal data concerning a User may be shared or disclosed with :
1. The Company and any company within its group, including but not limited to any subsidiary, holding or affiliated company ;
2. Any service provider, supplier, distributor, agent, and representative, including but not limited to credit and financial institutions, customer support, email service providers, event venues and service providers, IT service providers (including hosting providers), marketing service providers, research firms, mailing companies, shipping agents, on and off-ramp providers, the Company's Custody Partner(s) as described in the T\&Cs, merchants, and authenticators, analytics and search engine providers, advertisers and advertising networks solely to select and serve relevant advertisements to the User ;
3. Courts, law representatives, police, regulatory authorities, and other law enforcement agencies (in the event of a duty to disclose or share personal data in order to comply with any legal obligation) ;
4. In the event of selling or buying any business or assets, personal data may be disclosed to the prospective seller or buyer of such business or assets. 4/7 A published list of all third parties with whom the Company shares User data is not available, as this heavily depends on the specific use of the Services. However, Users seeking further information about entities with whom their data has been shared, or a specific list, can request this information by writing to [contact@suby.fi](mailto:contact@suby.fi)
In any case, the Company shall always ensure that, to the best of its knowledge, recipients of disclosed personal data have an adequate level of data protection.
***
### **7. DATA TRANSFER**
The User is informed that the data controller may, if applicable, transfer personal data to a third country or to an international organization that is subject to an adequacy decision by the European Commission. It is specified that, in the event of a transfer to a country or international organization that is not subject to an adequacy decision, this can only be carried out provided that appropriate safeguards are in place and that the individuals concerned by the personal data processing have enforceable rights and effective legal remedies, in accordance with the applicable regulations.
***
### **8. DATA RETENTION**
Personal data of Users is retained for as long as necessary to provide and complete the Service and fulfill the Company's obligations under a contract, law, or regulation. The User’s data is only accessed internally on a need to know basis, and it will only be accessed or processed if absolutely necessary. Personal data shall be deleted when no longer required by a relevant law or jurisdiction in which the Company operates. The main retention periods for the storage of personal data relating to Users of the Site are as follows:
1. Identification and contact data of a User : For the duration of the contractual relationship (as long as the User has not expressed the intention to no longer be a User of the Services or to no longer have their personal data retained, which must be done via a request sent to the following address : [contact@suby.fi](mailto:contact@suby.fi), up to a maximum of three (3) years from either the last order of services made by the User on the Site, or the date of termination of the last Service used by the User (whichever is most recent), after which personal data is no longer retained ;
2. Data collected during the registration for a Service (interrupted registration process) : Thirty (30) days from the entry of the email address by the User ;
3. Bank account and payout wallet details : For the duration of the contractual relationship, with subsequent retention of five (5) years for records related to Payout transactions ;
4. Bank card data (processed by payment service providers as processors) : Retained by payment service providers for as long as necessary to provide the service as processors ;
5. Data related to the execution of the contract (invoices, purchase history, payments, etc.) : Ten (10) years from either the last order of services made by the User via the Site, or the date of termination of the last Service concluded by the User (whichever is most recent) ;
6. Data related to the exercise of a right by a User : Five (5) years on top of the year of the request.
***
### **9. DATA SECURITY**
The Company employs technical and organizational measures to ensure the appropriate security level for processed personal information. These measures are designed to maintain the integrity, confidentiality, and availability of personal data.
The Company takes extensive steps to secure personal data on its systems. Dedicated staff are responsible for upholding data protection and security policies, conducting periodic reviews, and ensuring employees are informed about these practices.
Personal information is stored on secure servers. All data provided by Users is kept on these secure servers, and any information related to payment transactions is encrypted.
While every effort is made to safeguard personal information, the Company cannot guarantee the security of data during transmission, and any transfer is at the User’s risk. Upon receipt, stringent procedures and security measures are implemented to prevent unauthorized access.
The Company has established policies and procedures to securely manage information and protect personal data from unauthorized access. Regular assessments are conducted to ensure data privacy, information management, and security practices are maintained. These practices include :
1. Setting policies and procedures for secure information management ;
2. Restricting employee access to only the information necessary for their duties ;
3. Utilizing data encryption, authentication, and virus detection technology to prevent unauthorized access ;
4. Ensuring service providers comply with relevant data privacy laws and regulations ;
5. Monitoring websites through recognized privacy and security organizations ;
6. Conducting regular third-party audits of policies and practices ;
7. Performing background checks on employees and providing them with relevant training.
***
### **10. USER RIGHTS**
Based on the legal grounds for processing, which includes the User's consent, the User has the following rights under applicable regulations :
1. Right of access : The right to obtain from the data controller confirmation as to whether or not personal data concerning the User is being processed, and, where that is the case, access to the personal data ;
2. Right to rectification : The right to obtain from the data controller the rectification of inaccurate personal data concerning the User and to have incomplete personal data completed ;
3. Right to erasure : The right to obtain from the data controller the erasure of personal data concerning the user without undue delay, subject to legal retention obligations, especially when the personal data is no longer necessary in relation to the purposes for which it was collected or otherwise processed, when the User has withdrawn consent on which the processing is based, or when the processing is unlawful ;
4. Right to restriction of processing : The right to obtain from the data controller restriction of processing where the accuracy of the personal data is contested by the User, where the processing is unlawful, and the User opposes the erasure of the personal data and requests the restriction of their use instead, or where the data controller no longer needs the personal data for the purposes of the processing but they are required by the User for the establishment, exercise, or defense of legal claims ;
5. Right to object : The right to object, on grounds relating to the User's particular situation, at any time to the processing of personal data concerning them, including profiling ;
6. Right to object to direct marketing : The right to object, at any time, to the processing of personal data concerning the User for direct marketing purposes, which includes profiling to the extent that it is related to such direct marketing ;
7. Right to data portability : The right to receive the personal data concerning the User, which they have provided to a data controller, in a structured, commonly used, and machine-readable format, and to have the right to transmit that data to another data controller ;
8. Right to withdraw consent : The right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal ;
9. Right to give instructions regarding the post-mortem use of data : The right to define instructions regarding the fate of their personal data after their death.
The exercise of these rights, as identified in this article, is conducted by the User with the data controller by making a request addressed to the Company at the following address : [contact@suby.fi](mailto:contact@suby.fi).
It is specified that, to the extent the personal data concerned is necessary for the performance of the Services, the exercise by a User of their right to erasure, their right to object, their right to restrict processing, or their right to withdraw consent may result in the User being unable to access the Services, in whole or in part. Where this is the case, the Company will inform the User of the specific consequences before giving effect to the request, so that the User may confirm or reconsider their request.
***
### **11. CHILDREN’S PRIVACY**
This Article applies to Buyers and other individuals interacting with the Services as end consumers. Authorized Users and Merchants must in all cases be at least 18 years old, in accordance with Article 1 of the T\&Cs. Subject to the foregoing, the collection of personal data may only concern individuals who are at least fifteen (15) years old at the time of collection, unless the minor under fifteen (15) years old consents to this collection and this consent is accompanied by the consent of at least one holder of parental authority concerning them (parental authority is understood in the sense given by Article 371-1 of the French Civil Code). The collection of personal data is essential for the use of the Site and Services, so minors under fifteen (15) years old can only access the Services if they are authorized to do so by the holder(s) of parental authority concerning them.
Therefore, by requesting the Services and/or providing personal data on the Site, Users declare and\
guarantee that they are at least 15 years old or that they are authorized to use the Site and provide their personal data by the holder of parental responsibility concerning them.
The Company will not knowingly collect information from any person under fifteen (15) years of age. If any information is collected from such person without verification of parental consent, it will be deleted.
***
### **12. MODIFICATIONS AND UPDATES**
The Privacy Policy may be subject to corrective modifications or updates. Any changes will be\
accompanied by the indication, on this page, of the last revision date. As such, the User is invited to\
regularly review the latest version of this document, accessible in real-time on the Site.
\
Changes to the Privacy Policy may be subject to temporary notification on the Site or by any written means, including by email. Changes may only occur after a thirty (30) days’ prior written notice, unless they are required by law, more favorable to you or related to the addition of a new service or an extra functionality to the existing Service that did not exist prior to its introduction.
# Terms & Conditions - Merchant Of Record
Source: https://docs.suby.fi/v3-beta/docs/legal/terms-and-conditions-MoR
Last updated: Sept 18, 2026
## PREAMBLE
These Terms and Conditions (hereinafter the "T\&Cs") apply: (i) to the conditions of access and use of the website "[www.suby.fi](http://www.suby.fi)" (hereinafter the "Site" or the "Website"), the "Application", and any API developed and owned by the "Company" (as defined below); (ii) to the conditions of access and use of the "Services" (as defined below); and, more generally, (iii) to any interaction a "User" or "Merchant" (as defined below) may have with the Company, its affiliates, or any third party when using the Site, the Application, an API or the Services.
The Site is operated by the Company. In connection with the Services, the Company acts as the merchant of record ("MoR") and contractual reseller of the Merchant's Products to Buyers, as further described in Article 4 below. A Merchant must accept and fully comply with these T\&Cs, the Buyer Terms (where applicable) and the Privacy Policy before using the Services, an API or consulting the Site and the Application.
The preamble is a fundamental and binding component of the T\&Cs. Unless explicitly stated otherwise, the lists contained within the T\&Cs shall not be construed as restrictive or limiting in any way.
Capitalized terms have the meanings given to them in the Glossary below.
## GLOSSARY
API: Means any application programming interface provided by the Company.
Application: Means the mobile and/or web application software through which the Company offers its Services, including the data supplied with the software and the associated media.
Authorized User: Means a natural person operating or accessing a Merchant Account on behalf of a business using the Services.
Buyer: Means a natural person or legal entity who purchases a Product from a Merchant via the Service.
Buyer Terms: Means the terms and conditions governing the purchase of Products by Buyers via the Service, made available by the Company on the Website or at checkout, as amended from time to time.
Card Acceptance Agreement: Means Article 13 of these T\&Cs, which governs card and alternative payment method acceptance between the Company and the Merchant.
Company: Means Suby, a simplified joint-stock company (SAS) with a capital of 1,000 euros, having its registered office at Bureau 326, 59 rue de Ponthieu, 75008 Paris (France), registered under SIREN 990739302 (hereinafter the "Company", "Suby" or "we").
Intellectual Property: Means (i) rights in, and in relation to, any trademarks, logos, patents, registered designs, design rights, copyright and related rights, moral rights, databases, domain names, utility models, and including registrations and applications for, and renewals or extensions of, such rights, and similar or equivalent rights in any part of the world; (ii) rights in the nature of unfair competition rights and to sue for passing off and past infringement; and (iii) trade secrets, confidentiality and other proprietary rights, including know-how and other technical information.
Merchant / User: Means any natural person or legal entity that holds a Merchant Account and offers Products to Buyers via the Service.
Merchant Account: Means the account created by an Authorized User on the Site in order to access and use the Services.
Merchant of Record (MoR): Means the role in which the Company acts as the contractual seller of record for the sale of a Merchant's Products to a Buyer, executing the resale transaction in its own name, as described in Article 4.
Net Proceeds: Means the gross amount collected from a Buyer for a card or alternative-payment-method transaction, less applicable transaction fees, network fees, reserves, and any other deduction expressly provided for in these T\&Cs or required under applicable card scheme rules.
Payout: Means the net amount payable by the Company to the Merchant for transactions processed through the Service, after deduction of applicable service fees, taxes, refunds, chargebacks, reserves and any other amounts permitted under these T\&Cs.
Privacy Policy: Means the privacy policy of the Company which sets out the terms on which it processes personal data. By using the Services, the User consents to such processing and confirms that all data provided is accurate. The Privacy Policy is available at: Privacy Policy.
Product: Means any product or service offered by a Merchant via the Service, including but not limited to digital goods, software as a service (SaaS), online content, physical goods and non-digital services.
Services: Means the merchant of record service together with all other products, features, technologies or functions offered by the Company on its Website, Application or via its API.
Site / Website: Has the meaning given in the Preamble.
T\&Cs: Means these terms and conditions, including any annexes and referenced policies.
## ARTICLE 1 - USER AND MERCHANT ELIGIBILITY
The use of the Company's Services is exclusively reserved for commercial entities. Personal use for individual, non-commercial purposes is expressly prohibited.
Access to the Services is limited to Authorized Users who have been duly authorized by their respective businesses to act on their behalf. Authorized Users must provide the Company with valid credentials to confirm their binding authority when required. Failure to provide satisfactory proof of such authority may result in denial of access to the Services.
All Authorized Users must be at least 18 years of age. By using the Services, a User affirms that they are 18 years or older and possess the legal capacity to enter into a binding contract.
The Merchant represents and warrants that it is properly registered as a business or self-employed person under applicable law and is entitled to offer the Products it lists via the Service.
## ARTICLE 2 - MERCHANT ACCOUNT
To access and use the Services, a User must create a Merchant Account and provide all requested business and identity details. The Merchant Account type and associated obligations depend on whether the Merchant operates as:
* A merchant selling digital products or services (SaaS, subscriptions, online content); or
* A merchant selling physical products or non-digital services (e-commerce, freelance work, logistics-based businesses).
### 2.1 Account Information & Verification
* All information provided to the Company must be complete, accurate and truthful at all times.
* The Merchant is responsible for updating its information whenever changes occur, including changes to its country of establishment, tax residency, VAT or other tax identification numbers, and legal status.
* The Company may request additional supporting documents at any time to verify compliance or satisfy its own regulatory obligations.
* Failure to provide accurate information may result in suspension or termination of access to the Merchant Account, and in withholding of Payouts.
### 2.2 Security & Responsibility
* The Merchant is solely responsible for safeguarding its Merchant Account credentials, including login details, API keys, or authentication methods.
* Where the Merchant Account is linked to a self-custodial wallet used to receive Payouts, the Merchant assumes full responsibility for securing access to that wallet.
* The Company is not liable for losses resulting from unauthorized access to the Merchant Account, incorrect payout wallet addresses, or mishandling of funds by the Merchant.
* Any suspected unauthorized use must be reported immediately to the Company.
### 2.3 Specific Responsibilities for Each Merchant Type
Merchants selling physical products (e-commerce, logistics-based) must:
* Maintain accurate inventory levels to prevent overselling;
* Handle logistics, shipping and returns of the Product at their own cost;
* Provide any relevant information to enable the Company to ensure compliance with regional consumer protection laws applicable to the sale.
Merchants selling digital products (SaaS, online content, software) must:
* Provide their product-specific terms of use so that the Company can align Buyer-facing refund policies presented at checkout;
* Clearly define refund eligibility periods for their Product, particularly where chargeback risks exist.
### 2.4 Account Access & Updates
Access to the Merchant Account is provided via email notifications; the Merchant must ensure the security of its email credentials. The Company retains sole discretion to modify or terminate Merchant Account requirements or any aspect of the Services. Continued use of the Services after any such modification constitutes the Merchant's acceptance of the updated requirements.
The main functions of the Service - including the ability to publish checkout sessions for Products, process transactions, or receive Payouts - will not become active until the Merchant has successfully completed and been approved through the verification process described in Article 6.
## ARTICLE 3 - MERCHANT ACCOUNT SECURITY
### 3.1 General Security Obligations
* Use one-time passwords (OTP) sent via email for authentication purposes.
* Immediately report any unauthorized access attempts to the Company.
* Ensure the security of the email account used for OTP verification and Merchant Account access.
### 3.2 Merchant Payout Method
The Merchant must designate, via the Merchant Account, its preferred Payout method: (i) a bank account for Payouts in fiat currency; or (ii) a self-custodial wallet address for Payouts in supported stablecoins. The Merchant may change its designated Payout method at any time via the Merchant Account, subject to any verification requirements applicable to the new method.
This payout mechanism operates independently from the Company's role as Merchant of Record described in Article 4: the Company collects and processes payment from the Buyer as principal, and separately executes Payouts to the Merchant's designated bank account or wallet, net of the amounts described in Article 11.
The Merchant is solely responsible for providing valid and correct bank account details or payout wallet address, as applicable, and for updating them as needed. Prior to withdrawal, funds corresponding to the Merchant's Suby Balance are held by the Company's Custody Partner in accordance with Article 16; neither the Company nor the Merchant has access to the private keys controlling those funds. Once a Payout has been executed to the Merchant's designated bank account or self-custodial wallet address, the Merchant is fully responsible for securing access to it, including any associated private keys where applicable. Where the Merchant elects to receive Payouts by bank transfer, the Company processes such Payouts via its banking or payment partners in accordance with standard bank transfer rails and timelines; the Company is not liable for delays or errors caused by the Merchant's bank or intermediary financial institutions. The Company cannot reverse, recover, or redirect a Payout once it has been executed to the designated bank account or wallet. In the event of an incorrect bank account or payout wallet address, a compromised Merchant wallet, or loss of wallet or bank account access, the Company cannot assist in recovering the funds beyond what its banking partners may reasonably support for bank-transfer Payouts.
### 3.3 Email & Device Security
* The Merchant must ensure the security of its email account, as it serves as the platform's authentication method.
* If the Merchant's email is compromised, it must notify the Company immediately.
* The Merchant must keep its browser and operating system up to date, including the latest security patches and antivirus software.
### 3.4 Prohibited Security Risks
To prevent unauthorized access, the Merchant must not:
* Share Merchant Account credentials, API keys, or payout wallet access with third parties;
* Allow remote access to its devices unless necessary for technical support;
* Use autofill features that store passwords in the browser;
* Attempt to bypass, disable, or interfere with two-factor authentication (2FA).
### 3.5 Liability Disclaimer
The Merchant is responsible for securing its own systems, including computers, software, and mobile devices used to access the Services. The Company does not guarantee that the Services will be free from bugs, malware, or cyber threats; the Merchant must implement adequate cybersecurity measures on its end.
## ARTICLE 4 - DESCRIPTION OF THE SERVICE; ROLES OF THE PARTIES
The Service enables the Merchant to offer its Products to Buyers via the Merchant's own website or other sales channel. Purchases are completed through the checkout solution provided by the Company, whether hosted by the Company or embedded on the Merchant's website, where the transaction is processed.
In this setup, the Company acts as the merchant of record and contractual reseller of the Product: the Company enters into the resale transaction with the Buyer in its own name. The responsibilities of the Parties towards each other in connection with the sale of a Product are set out below.
### 4.1 The Company is responsible for:
* entering into the resale transaction with the Buyer;
* collecting and processing payment from the Buyer, in fiat currency and/or supported cryptocurrencies;
* issuing the invoice or payment confirmation to the Buyer;
* calculating, collecting and remitting applicable sales taxes, VAT or other indirect taxes based on the Buyer's billing address and applicable law, as further described in Article 10;
* providing related administrative services, such as fraud prevention, dispute handling and merchant fee processing;
* settling the resulting Payout to the Merchant in accordance with Article 11.
### 4.2 The Merchant remains solely responsible for:
* providing, delivering and ensuring access to the Product to the Buyer;
* ensuring that the Product performs as described and complies with applicable laws and regulations, including after resale to the Buyer;
* ensuring that the Product does not infringe any third-party rights, including Intellectual Property rights;
* determining refund eligibility for the Product and providing the information needed by the Company to process refund requests under Article 12;
* managing any Buyer-facing customer service or post-sale support relating to the Product itself (as opposed to the payment transaction, which is handled by the Company);
* fulfilling any consumer rights or remedies enforceable by the Buyer in relation to the Product;
* ensuring it is properly registered as a business under applicable law and reporting and paying all applicable direct taxes (including income or corporate tax) on Payouts received, as further described in Article 10.
Upon and after resale of a Product, the Merchant remains solely responsible for the nature, functionality, legality, availability, quality and performance of that Product. The Company does not develop, test, host, maintain or otherwise provide the Product itself.
### 4.3 Buyer information
The Merchant shall ensure that Buyers are clearly informed, before completing a transaction, that payment will be processed by the Company acting as merchant of record - for example in the Merchant's terms of sale, FAQ, or checkout flow. Product-specific terms and conditions presented by the Merchant to Buyers must be provided clearly before checkout; in the event of any conflict between such Product-specific terms and the Buyer Terms or these T\&Cs, the Buyer Terms and these T\&Cs shall prevail.
## ARTICLE 5 - DISCLAIMERS
The Company acts as merchant of record and contractual seller for the purposes of processing transactions, issuing invoices, handling applicable indirect taxes, collecting payments, and fulfilling related administrative obligations. The Company's role is strictly limited to these functions. Notwithstanding the Company's role as merchant of record and its resulting obligations towards the Buyer, the Parties agree that, as between the Company and the Merchant:
* the Merchant is solely responsible for the content, quality, delivery, and compliance of its Products;
* the Company shall not be deemed to assume any of the Merchant's obligations towards the Buyer, including delivery of the Product, provision of support, compliance with consumer protection laws, or the accuracy and legality of Product information;
* the Company shall not be deemed to create, own, control, review, or endorse any Product offered by the Merchant, and assumes no responsibility for its legality, functionality, accuracy, performance, or compliance with applicable law or Buyer expectations.
While the Company facilitates the technical processing of refunds and chargebacks as part of payment handling (Article 12), the Merchant remains solely responsible for determining refund eligibility, handling return requests, and resolving the underlying dispute with the Buyer regarding the Product itself.
Any template, sample document, guidance, or other material provided by the Company via the Service is for general informational purposes only and does not constitute legal, tax, or compliance advice. The Merchant is solely responsible for ensuring that its business, Products, and operations comply with all applicable laws and regulations.
## ARTICLE 6 - MERCHANT VERIFICATION AND COMPLIANCE
To comply with applicable laws and regulations, the Company requires all Merchants to undergo a verification process before accessing the payment-related functions of the Service. This process may include identity verification, anti-money laundering (AML) screening, and other compliance (KYC/KYB) checks.
The Merchant agrees to provide accurate and complete information as requested, including details regarding its legal entity, ownership structure, authorized representatives, business activities, and jurisdiction, and to keep this information up to date.
The Company may request additional information or documentation at any time, whether during onboarding or throughout the Merchant's use of the Service, and may engage third-party providers to carry out verification and compliance tasks.
Failure to provide required information or documentation, or providing false or misleading information, may result in suspension or termination of access to the Service, withholding of Payouts, or other action deemed appropriate by the Company.
The main payment-related functions of the Service - publishing checkout sessions, processing transactions, or receiving Payouts - will not become active until verification has been successfully completed and approved.
## ARTICLE 7 - USE OF THE SERVICE; PROHIBITED USE
The Service is intended for Merchants who wish to sell Products to Buyers using the Service's features as described on the Website. Using the Service for any other purpose is not permitted.
The Company may restrict the availability of the Service to Merchants or Buyers located in certain countries or territories. The relevant list is published on the Website and may be updated from time to time; the Service may not be used to offer Products to Buyers located in such countries or territories.
The Merchant shall not offer, via the Service, any Product included on the Company's prohibited or restricted products and merchant category (MCC) list, published and maintained on the Website and referenced in the Card Acceptance Agreement (Article 13.4). This list is incorporated by reference into these T\&Cs and may be updated by the Company from time to time to reflect card scheme rules, acquirer requirements, or applicable law.
Without limiting any of the Merchant's other obligations, the Merchant shall not, and shall not allow any Authorized User to:
* transfer the Merchant Account to anyone else without the Company's permission;
* use the Service for any unlawful, obscene, or immoral purpose;
* submit false or misleading information;
* engage in fraudulent, illegal, or abusive behaviour;
* offer Products subject to licensing, authorization or registration requirements (including but not limited to financial services, gambling, or medical services) or included on the prohibited products list referenced above;
* attempt to gain unauthorized access to, or interfere with, the security or infrastructure of the Service;
* upload or transmit malicious code, or use any device or routine that could disrupt the proper functioning of the Service.
The Company may screen Merchant content submitted via the Service and may remove, disable, or reject any content that conflicts with these T\&Cs, at its sole discretion and without prior notice.
## ARTICLE 8 - FEES AND PAYMENTS FOR THE SERVICE
As part of its role as merchant of record, the Company is entitled to a service fee for each transaction processed through the Service. This fee compensates the Company for payment processing, invoicing, tax handling, dispute management, and related administrative services. The service fee consists of:
* a percentage-based commission on the gross transaction amount; and
* a fixed fee per transaction,
as specified in the pricing schedule made available to the Merchant via the Website, the Merchant Account, or the applicable commercial agreement. Applicable fees, together with any amounts described in Articles 10, 11, 12 and 13, are deducted before the Payout is made to the Merchant.
Fees may vary depending on the payment method used by the Buyer (fiat or supported cryptocurrency), the Merchant's plan, transaction volume, risk profile, and operational or infrastructure costs. Card and alternative-payment-method transaction pricing is further specified in the Card Acceptance Agreement (Article 13.6).
Where no separate commercial agreement covering pricing has been signed by the Parties, or such an agreement does not address a given fee, the Company's standard default pricing shall apply automatically, namely a transaction fee of 4% of the gross transaction amount plus a fixed amount of \$0.40 per transaction, together with the ancillary fees set out in Article 13.6. Continued use of the Services by the Merchant in the absence of a signed pricing agreement constitutes acceptance of these default rates. The Company may update its default pricing with at least fifteen (15) days' written notice to the Merchant.
The Company may access various additional features that are free of charge or paid; descriptions and pricing for such features are available on the Website or within the Service. By using a paid feature, the Merchant agrees to pay the applicable fee. The Company may update its pricing or change the availability of features (including making a free feature paid) at any time, subject to at least fifteen (15) days' prior notice via the Website, the Service, or email. The Merchant will not be charged for a newly priced feature without being notified and given the opportunity to opt out by discontinuing use of that feature.
### Confidentiality of Pricing
The fee structure agreed with a Merchant is confidential commercial information. The Merchant agrees not to disclose such pricing terms to third parties without the Company's prior written consent. Breach of this obligation may result in suspension or termination of the Merchant Account.
## ARTICLE 9 - SELF-BILLING OF MERCHANT PAYOUTS
The Company shall issue self-billed invoices on behalf of the Merchant to document the amounts payable by the Company to the Merchant under these T\&Cs. The Merchant agrees not to issue separate invoices to the Company for these Payouts.
The Company shall make self-billed invoices available to the Merchant via the Merchant Account or another agreed method. The Merchant undertakes to review each invoice and to notify the Company in writing of any objection within three (3) business days; in the absence of such notice, the invoice is deemed accepted.
The Merchant shall promptly inform the Company of any change to its tax registration status, invoicing details, or other information affecting the accuracy of self-billed invoices. Where the Merchant is VAT-registered, or otherwise qualifies as a taxable person for VAT purposes, the Merchant confirms that no VAT shall be applied to Payouts received from the Company and acknowledges that such Payouts may be subject to a reverse-charge mechanism where applicable.
## ARTICLE 10 - TAXES AND INVOICING
### 10.1 Indirect taxes - the Company's responsibility as MoR
Acting as merchant of record, the Company is responsible for calculating, collecting, and remitting any applicable sales tax, VAT, or other indirect tax associated with the sale of a Product to a Buyer through the Service, based on the Buyer's billing address and applicable tax law. The Company shall issue invoices or payment confirmations to Buyers in its own name and, where legally required, include the applicable taxes.
For any transaction processed via the Service, the Merchant shall not: (i) issue any invoice or receipt to the Buyer for that transaction; (ii) make any separate request or demand for payment from the Buyer; or (iii) collect, charge, or account for any tax in connection with the transaction. All invoicing, payment collection, and applicable indirect tax handling shall be carried out exclusively by the Company as part of the Service.
The Company will make available to the Merchant, via the Merchant Account, regular transaction records reflecting gross amounts received, fees deducted, taxes handled, and Payout amounts. These records are intended for reconciliation and informational purposes and do not replace the Merchant's own accounting or tax records.
### 10.2 Direct taxes - the Merchant's responsibility
The Merchant remains solely responsible for the declaration, payment, and compliance with all direct taxes applicable to its business, including income tax, corporate tax, and any self-employment contributions on Payouts received from the Company, which the Merchant shall treat as taxable business income in accordance with applicable tax law.
Payouts made by the Company to the Merchant constitute consideration for the sale of Products and shall not be treated as royalties, licence fees, or payments for the use of Intellectual Property. The Merchant confirms that the Company is authorized to resell the Product for each transaction and acquires no rights beyond what is necessary to enable such resale.
### 10.3 No tax advice
The Company does not provide tax, legal, or accounting advice. The Merchant is encouraged to consult a qualified tax advisor regarding its specific obligations, including with respect to Payouts settled in stablecoins.
### 10.4 Records and cooperation
The Merchant agrees to retain records relating to Products sold via the Service and to cooperate with the Company in providing reasonable documentation for tax or audit purposes upon request.
### 10.5 Consequences of non-compliance
Failure by the Merchant to provide accurate tax information, or to comply with its tax obligations, may result in suspension or termination of access to the Service, withholding of Payouts, or reporting to competent authorities where legally required. The Company shall not be liable for penalties, interest, or other consequences arising from the Merchant's non-compliance with applicable tax law.
## ARTICLE 11 - PAYMENTS AND PAYOUTS
Amounts owed to the Merchant are held pending withdrawal in accordance with Article 16. The Company collects payment from Buyers for transactions processed through the Service, in fiat currency via the Company's regulated acquiring and payment partners (see Article 13 for card and alternative payment methods), and/or in supported cryptocurrencies processed on-chain. After deducting applicable service fees, taxes, refunds, chargebacks, reserves, and other amounts permitted under these T\&Cs, the Company settles the resulting Payout to the Merchant using the payout method designated under Article 3.2: (i) by bank transfer in fiat currency to the Merchant's designated bank account; or (ii) by converting the relevant amount into supported stablecoins and transferring it on-chain to the Merchant's designated self-custodial wallet address.
The Merchant is solely responsible for ensuring that its designated bank account details or payout wallet address are accurate and up to date. Payouts, once executed to the designated bank account or wallet, are irreversible; the Company cannot recover, reverse, or redirect funds once sent, and is not liable for losses arising from incorrect payout details or from the Merchant's mismanagement of its bank account or wallet.
If the Merchant elects to convert stablecoins received as a Payout into fiat currency, such conversion must be performed via third-party off-ramp providers. Exchange rates, conversion fees, availability, and execution are determined exclusively by such providers, and the Company bears no responsibility for exchange rate volatility, conversion outcomes, or losses resulting from off-ramping.
Payouts are executed in accordance with the schedule, thresholds, and process published on the Website or made available via the Merchant Account, and, for card transactions, in accordance with the settlement timing set out in Article 13.3. The Company may modify the Payout schedule, thresholds, and related procedures at any time, with such changes taking effect upon publication.
The Company may withhold or delay a Payout to: (i) comply with applicable law or a regulatory obligation; (ii) investigate a suspected fraudulent, illegal, or prohibited transaction; (iii) maintain a reserve for potential chargebacks or refunds as described in Article 12.4 and Article 13.3; or (iv) enforce these T\&Cs.
The Company may deduct or offset any amount owed by the Merchant to the Company - including fees, refunds, chargebacks, penalties, or indemnification claims under Article 28 - from current or future Payouts, or from any reserve held under Article 12.4 or Article 13.3. The Merchant is responsible for all costs associated with receiving a Payout, including any network or blockchain fees.
## ARTICLE 12 - REFUNDS AND CHARGEBACKS
All refunds and chargebacks related to transactions processed through the Service are handled by the Company. The Merchant shall not process or accept any refund or return independently for such transactions outside the Service.
The Merchant is responsible for determining refund eligibility for its Products and must request any refund via the functionality provided in the Merchant Account. The Company will process such requests in accordance with the Service's procedures and applicable law.
Notwithstanding the above, the Company may, at its sole discretion, issue a refund to a Buyer without prior instruction from the Merchant where:
* required by law or applicable consumer protection regulation;
* mandated by a card scheme, payment provider, or regulatory authority;
* due to a technical error, duplicate payment, or manifest mistake; or
* there is a suspected fraudulent payment or a payment dispute.
The Merchant shall reimburse the Company for any amount refunded under the preceding paragraph, unless the refund is caused solely by the Company's gross negligence or intentional non-performance.
In the event of a chargeback initiated by a Buyer, the Company will notify the Merchant and may request supporting documentation to contest the claim; the Merchant shall cooperate promptly and in good faith. The Merchant bears full financial responsibility for chargebacks related to its Products, including the original transaction amount and any associated fees or penalties, unless the chargeback is solely attributable to an error by the Company.
The Company may deduct amounts related to refunds or chargebacks from the Merchant's Payouts, from the reserve described below, or may invoice the Merchant directly.
### 12.4 Rolling reserve (general)
Where a Merchant's chargeback rate, refund rate, or overall risk profile so warrants, the Company may withhold a rolling reserve from the Merchant's Payouts to cover potential chargebacks, refunds, or other financial exposure. The applicable reserve percentage and holding period are determined by the Company based on the Merchant's risk profile (including its business model, MCC, chargeback and refund history, and transaction volume), as communicated to the Merchant via the Merchant Account or the applicable commercial agreement, and may be adjusted by the Company from time to time to reflect changes in the Merchant's risk profile.
As a general threshold applicable across payment methods, if the Merchant's monthly chargeback rate or refund rate exceeds zero point seventy-five percent (0.75%) of transactions, the Company may increase the reserve percentage, extend the reserve holding period, or suspend Payouts until the Merchant's risk exposure is resolved. Reserved amounts are released on a first-in-first-out basis at the end of the holding period applicable at the time each amount was withheld, unless applied against outstanding chargebacks, refunds, or other amounts owed by the Merchant, or unless a longer period is required under applicable law, card scheme rules, or acquirer requirements.
## ARTICLE 13 - CARD ACCEPTANCE AGREEMENT
This Article constitutes the card acceptance agreement between the Company and the Merchant, incorporating the applicable rules of the card schemes (including Visa and Mastercard) and any other supported alternative payment method ("APM") network. By accepting these T\&Cs, the Merchant acknowledges and agrees to all terms set out in this Article. Pricing applicable to card and APM acceptance is defined exclusively in the commercial agreement or pricing schedule signed separately between the Parties, or, in the absence thereof, in the default pricing referenced in Article 8 and Article 13.6. All other conditions of card acceptance - including billable events, reserves, settlement, risk, compliance, dispute management, and termination - are governed exclusively by this Article 13.
### 13.1 Role, structure and accepted payment methods
* The Company acts as merchant of record for all card and APM transactions initiated through its infrastructure. The Merchant operates under its own business model and regulatory framework in relation to its Products.
* The Company charges the Buyer, receives funds from its acquiring partners, and remits Net Proceeds to the Merchant as a Payout, subject to the deductions, reserves and suspension rights set out in this Article.
* "Net Proceeds" means the gross amount collected from Buyers, less applicable transaction fees, network fees, reserves, and any other deduction expressly provided for in these T\&Cs or required by applicable card scheme rules.
* The Merchant shall not process, refund, or initiate chargebacks directly with acquirers or card schemes. All such actions must be initiated exclusively through the Company, which retains sole discretion to initiate, approve, decline, or process refunds, dispute responses, and chargeback management, in accordance with card scheme rules, acquirer requirements, risk controls, or consumer protection standards.
* Card and APM acceptance is limited to methods explicitly approved by the Company, including its hosted checkout, direct API integration, mobile-optimized flows, or approved partner-embedded pages. The Merchant shall not implement unapproved or standalone integrations.
* The Company retains sole discretion to approve or decline any merchant category code (MCC), payment flow, transaction currency, or Buyer country of residence. Only approved categories and jurisdictions will be activated.
* Nothing in this Article grants the Merchant the right to act as a payment service provider or agent of the Company. The Merchant remains fully independent and responsible for its own licensing obligations and its relationships with its own users.
Accepted payment methods (non-exhaustive, subject to change): card networks - Visa, Mastercard (credit and debit), with 3-D Secure 2.0 where applicable; alternative payment methods - as made available on the Website from time to time. The Company may modify, add, or remove specific payment methods and will, where possible, inform the Merchant in advance; it may suspend or disable a payment method immediately where required by card schemes, acquiring partners, applicable law, or risk controls.
### 13.2 Billable events and transaction controls
The following events are billable under these T\&Cs: authorization attempt; capture or settlement; refund; chargeback initiation; account updater or token usage; and dispute-prevention tools and services (including RDR, Ethoca, Verifi or equivalent).
The maximum transaction value is defined dynamically by the Company based on business model, MCC, or payment method. The Merchant shall not attempt to submit a transaction exceeding the defined limit without the Company's prior written consent. The Company does not impose a default daily per-card transaction limit unless required by applicable network rules or specific anti-fraud requirements; volume caps may be introduced dynamically based on risk profile or compliance needs and will be communicated to the Merchant in writing where applicable. Certain billable events may trigger pass-through fees imposed by card schemes, acquiring partners, or related service providers (including account updater services, tokenization services, and similar network fees); such pass-through fees may be deducted from Net Proceeds or applied against the rolling reserve, and will be itemized in reporting where possible.
### 13.3 Reserve and settlement
This section governs the rolling reserve, settlement timing, the Merchant's financial responsibility, and the escalation protocol applicable to a Merchant Debit Balance.
### 13.3.1 Rolling reserve
A rolling reserve may be withheld on card transactions, at a percentage determined by the Company based on the Merchant's risk profile in accordance with Article 12.4. The reserve may be used by the Company at any time to fund Buyer refunds or mitigate transaction-related financial exposure, including but not limited to chargebacks, fraud, or insolvency. Net Proceeds are generally settled on a T+3 to T+5 business-day basis.
### 13.3.2 Release of the reserve
The rolling reserve is released on a first-in-first-out basis at the end of the holding period applicable at the time of withholding, as determined under Article 12.4, unless used to cover refund obligations or otherwise offset, withheld, or deferred where required by card scheme rules, acquiring partner requirements, or applicable law, or to cover pending or reasonably anticipated chargebacks, refunds, disputes, cancellations, fraud losses, or network fines. Any utilized portion of the reserve is automatically replenished from future transaction proceeds. Reserve payouts follow the standard settlement cycle and are disbursed within three (3) to five (5) business days of their respective release date.
### 13.3.3 Chargeback and refund rate threshold
For the purposes of this Article, "chargeback rate" and "refund rate" mean the chargeback-to-transaction ratio and the refund-to-transaction ratio, calculated in accordance with the applicable card scheme rules (or, if not otherwise specified, the total number of first chargebacks or refunds received in a calendar month divided by the total number of captured transactions in the same month, expressed as a percentage).
If the Merchant's monthly chargeback rate or refund rate exceeds 0.75% (or any lower threshold required by applicable card scheme rules or acquiring partner requirements), the Company may suspend all payouts and delay settlement until the risk exposure is resolved. The overall compliance, remediation, and termination framework is set out in Article 13.3.4 below. The Company will notify the Merchant promptly after exercising such right, except where immediate action is required to comply with card scheme obligations or to prevent active fraud.
### 13.3.4 Financial responsibility and debit balance protocol
(a) Financial responsibility. The Merchant is solely and fully responsible to the Company for any financial exposure arising from transactions processed through the Company's infrastructure, including but not limited to chargebacks, refunds, fraud losses, and card scheme fines, regardless of origin or cause. The rolling reserve constitutes only a partial guarantee and does not cap the Merchant's total liability.
(b) Debit balance. Where the rolling reserve is insufficient to cover financial exposure, the unpaid amount constitutes a legally binding debt owed by the Merchant to the Company (the "Debit Balance"). The Company will notify the Merchant in writing of any Debit Balance, including a breakdown of the underlying transactions and the amount owed.
(c) Automatic recovery. The Company will recover any Debit Balance automatically by: (i) deducting it from the Merchant's future settlement proceeds; and/or (ii) drawing on the rolling reserve. If these T\&Cs are terminated or the Merchant Account is closed before the Debit Balance is fully recovered, the remaining balance becomes immediately due and legally binding, and the Company reserves the right to pursue recovery through any available legal means.
(d) Escalation protocol: Step 1 - Notification: the Company notifies the Merchant in writing of the Debit Balance or risk event, with all necessary details, and makes its payments team available to coordinate remediation. Step 2 - Activation of chargeback protection: if the chargeback rate increases and exposes the Company to risk, the Company will activate chargeback protection programs (RDR, Ethoca alerts, Verifi or equivalent); costs of these programs, as invoiced by the relevant providers, are passed through to the Merchant and deducted from Net Proceeds or applied against the rolling reserve, with full transparency as to costs and covered transactions. Step 3 - Full account suspension: if the Debit Balance remains unresolved, or suspension rights are triggered, the Company may suspend all processing and settlement activity; the Merchant will be informed in writing of the triggering event and the conditions required to restore service.
(e) Survival. The Merchant's financial obligations under this section survive termination of these T\&Cs. Any Debit Balance not recovered before or upon termination remains immediately due and legally binding.
(f) Account closure with a debit balance. If the Merchant requests account closure or ceases processing activity while a Debit Balance exists or is reasonably anticipated (including pending disputes, chargebacks, or refunds), all such amounts become immediately due. The Company may offset any amount owed by the Merchant against any amount payable to the Merchant, including future settlements, reserves (released or not), and any other funds held or processed by the Company. The Merchant shall reimburse the Company's reasonable collection costs, including external legal fees where applicable.
### 13.4 Risk, compliance, and network rules
### 13.4.1 General compliance with network rules
* All activity must comply with Visa, Mastercard, and other applicable network rules, including those relating to chargebacks, MCC classifications, and permitted countries.
* The Company retains full discretion regarding which jurisdictions, currencies, and use cases may be supported. Transactions from unauthorized countries or business models will be blocked or refunded.
* The Merchant shall not contract separately or independently with card schemes for services provided under these T\&Cs.
### 13.4.2 Chargeback threshold and remediation
If the Merchant's chargeback rate exceeds 0.75% in a calendar month (or a lower threshold required by applicable card scheme rules or acquiring partner requirements), the Company may: suspend settlements; increase reserves; impose additional fraud controls; or suspend card processing and require a formal remediation plan.
If the chargeback rate remains above 0.75% for two consecutive months, the Company may terminate card acceptance services with immediate effect. Unless immediate action is required by card scheme rules or to prevent active fraud, the Company will provide written notice and a remediation period of at least seven (7) calendar days before exercising its termination rights under this section.
Remedial action for a chargeback rate exceeding 0.75% may range up to, and include, account closure and immediate termination — this constitutes the hard ceiling of the Company's remediation escalation under this Article.
### 13.4.3 Indemnification
The Merchant shall indemnify and hold the Company harmless from direct losses, card scheme penalties, or damages resulting from intentional fraud, gross negligence, or material violations of card scheme rules committed by the Merchant. This indemnification does not apply to routine operational issues, unintentional errors, or chargebacks arising from valid Buyer disputes. This section is supplementary to, and does not limit, any other indemnification or allocation of liability set out elsewhere in these T\&Cs, including Article 28.
### 13.4.4 Dispute prevention services
The Company may, at its discretion or where required by card schemes or acquiring partners, activate dispute prevention or resolution programs (including but not limited to Rapid Dispute Resolution (RDR), Ethoca Alerts, Verifi, or equivalent). Such activation may occur if the Company identifies a significant increase in fraud or chargeback indicators, or where card schemes or acquiring partners require it. The Company will inform the Merchant before or immediately after activation. Costs charged by program providers are passed through to the Merchant and deducted from Net Proceeds or applied against the reserve, with full transparency as to amounts and covered transactions.
### 13.4.5 Chargeback dispute process
Upon receiving a chargeback claim, the Company will promptly notify the Merchant, providing the reason code, transaction reference, chargeback amount, and available dispute information. The Merchant has seven (7) calendar days from notification to submit evidence for representment. If no evidence is submitted within this period, the Company may accept the chargeback without recourse for the Merchant. The Company will assess representment eligibility based on the evidence provided and applicable card scheme rules; the final decision to pursue representment rests with the Company.
### 13.4.6 PCI-DSS and data security
* The Merchant must at all times comply with the Payment Card Industry Data Security Standard (PCI-DSS) requirements applicable to its role and transaction volumes.
* The Merchant shall not store, process, or transmit cardholder data (including full card numbers, CVV/CVC codes, or PINs) unless strictly necessary and fully compliant with PCI-DSS.
* In the event of an actual or suspected data breach involving cardholder data, the Merchant must notify the Company immediately and fully cooperate with any forensic investigation. All costs related to the forensic investigation, card scheme fines, or card reissuance attributable to the Merchant shall be borne solely by the Merchant.
### 13.5 Duration and termination of card acceptance
### 13.5.1 Standard termination
Card acceptance services may be terminated by either Party upon thirty (30) days' written notice.
### 13.5.2 Immediate termination
The Company may terminate card acceptance services with immediate effect, without notice or penalty, in the event of: a material breach of these T\&Cs by the Merchant; the Merchant's chargeback or fraud rate reaching the termination conditions set out in Article 13.4.2, subject to the notice and remediation process described therein, unless immediate action is required by card scheme rules, acquiring partners, or applicable law; the Merchant's insolvency, liquidation, or cessation of business; or a termination requirement imposed by card scheme rules, acquiring partners, or applicable law.
### 13.5.3 Reserve retention after termination
Upon termination, transaction processing ceases immediately. Rolling reserves and any other withheld or pending amounts may be retained by the Company for a minimum period of one hundred and twenty (120) days following the date of the last processed transaction, and longer if required by card scheme rules, acquiring partner requirements, applicable law, or the need to cover pending chargebacks, refunds, disputes, cancellations, fraud losses, or network fines.
Chargebacks received after termination will be deducted from retained amounts. If retained amounts are insufficient, the outstanding balance constitutes a debt owed by the Merchant to the Company, recoverable in accordance with Article 13.3.4. Any remaining balance, net of outstanding obligations, will be released following final reconciliation.
### 13.6 Pricing - reference to the commercial agreement
Pricing applicable to card acceptance services (transaction fees, chargeback processing fees, representment fees, card scheme fees, and any other applicable charge) is defined exclusively in the commercial agreement or pricing schedule signed separately between the Company and the Merchant. All other conditions relating to card acceptance are governed by this Article 13.
For reference only, and subject to an individual agreement, standard default pricing is as follows: cards: 4% + \$0.40 per transaction | chargeback processing: \$25 per Visa dispute, \$50 per Mastercard dispute. These rates may vary depending on payment method, region, and risk profile.
## ARTICLE 14 - REGULATORY QUALIFICATION
The Parties expressly acknowledge and agree that:
* the Company acts as merchant of record (MoR) and principal seller in all transactions with Buyers, purchasing and reselling Products in its own name;
* the Company does not provide payment services within the meaning of Directive (EU) 2015/2366 (PSD2), as it does not execute payment transactions on behalf of the Merchant or a third party;
* the Company does not itself hold or control the private keys to funds corresponding to the Merchant's Suby Balance, which are held by a regulated third-party Custody Partner in accordance with Article 16, pending withdrawal by the Merchant;
* any conversion between fiat currency and stablecoins is performed by the Company for its own account, as part of its commercial resale activity.
## ARTICLE 15 - THIRD-PARTY MATERIALS
Certain features of the Website, Application, or Services may enable the Merchant to access or interact with information, products, services or content provided by third parties ("Third-Party Materials"), including embedded content, hyperlinks, APIs, off-ramp providers, or external integrations.
The Company does not control, endorse, or assume responsibility for any Third-Party Materials, including their accuracy, legality, or security, and may block, restrict, or remove access to them at its sole discretion. The Merchant engages with Third-Party Materials at its own risk and subject to the relevant third party's own terms.
## ARTICLE 16 - CUSTODY OF FUNDS AND MERCHANT BALANCE
Amounts payable to the Merchant following a sale are reflected as a balance in the Merchant Account (the "Suby Balance") pending withdrawal by the Merchant. The Suby Balance is a record of the amount owed by the Company to the Merchant; it does not constitute a deposit, e-money, or a custodial digital asset account held by the Company.
The Company does not hold, control, or have access to the private keys, seed phrases, or wallet credentials associated with any wallet used in connection with the Services, whether the Merchant's own withdrawal destination or otherwise. Funds corresponding to the Suby Balance are held, pending withdrawal, by a regulated third-party custodian or payment institution engaged by the Company (the "Custody Partner"). Neither the Company nor the Merchant has direct access to the private keys or credentials controlling the funds held by the Custody Partner; access and release of funds are governed by the Company's agreement with the Custody Partner and are triggered by a withdrawal instruction validly submitted by the Merchant via the Merchant Account.
Upon a withdrawal request, the Company instructs the Custody Partner to release the corresponding funds, which are transferred directly to the bank account or self-custodial wallet address designated by the Merchant under Article 3.2. From the point such funds are received at the Merchant's designated bank account or wallet, the Merchant assumes full and sole responsibility for their custody and security, in accordance with Article 3.2.
The Company shall not be liable for any act, omission, insolvency, security incident, or operational failure of the Custody Partner, except to the extent caused by the Company's own gross negligence or wilful misconduct in selecting or instructing the Custody Partner. The Company does not guarantee the availability, solvency, or continued operation of any Custody Partner and may change its Custody Partner at any time, with notice to the Merchant where the change materially affects withdrawal timelines or processes.
For the avoidance of doubt, this Article governs the holding of funds between collection from the Buyer and withdrawal by the Merchant. The Company's role in collecting funds from Buyers as merchant of record is governed by Articles 4, 11 and 13.
## ARTICLE 17 - NO FIDUCIARY DUTIES
These T\&Cs do not create or impose any fiduciary duty on the Company. The Company does not act as a trustee, agent, or financial custodian for the Merchant. To the fullest extent permitted by law, the Merchant acknowledges that the Company's only obligations towards it are those expressly set out in these T\&Cs, and any potential fiduciary obligation is irrevocably disclaimed and waived.
## ARTICLE 18 - INTELLECTUAL PROPERTY
All rights, title, and interest in and to any software, services, and Intellectual Property developed, provided, or made available by the Company or its affiliates - including the Application, Website, API, developer tools, sample source code, documentation, and the technology and proprietary algorithms used in the Company's payment infrastructure - remain the exclusive property of the Company and its licensors. All Company materials and Services are protected by Intellectual Property laws and international treaties.
Subject to these T\&Cs, the Company grants the Merchant a worldwide, non-exclusive, non-transferable, non-sublicensable and revocable licence to access and use the Service for its intended purpose, for internal business use only, for as long as these T\&Cs remain in force.
## ARTICLE 19 - RESTRICTIONS ON USE OF COMPANY MATERIALS
Unless authorized in writing by the Company, the Merchant shall not: use or exploit Company materials for unauthorized commercial purposes; sell, sublicense, lease, rent, assign, or otherwise transfer the Services or Company materials to a third party; remove or alter any trademark or Intellectual Property notice; modify, copy, adapt, or create derivative works of Company software or materials; or reverse-engineer, disassemble, or decompile any Company software.
Unauthorized use may result in immediate termination of the Merchant Account and legal action, including for damages and injunctive relief.
## ARTICLE 20 - COMPANY TRADEMARKS
A non-exhaustive list of Company trademarks includes "SUBY" and any other business or service name, logo, sign, graphic, page header, button icon, or script belonging to the Company or its licensors ("Company Trademarks").
Unless authorized in writing, the Merchant may not copy, imitate, modify, or use the Company Trademarks in a way that misrepresents affiliation, implies endorsement, creates confusion, or disparages the Company. The Merchant may use Company-provided HTML logos solely to direct traffic to the Company's official Services, without modifying or distorting them. Unauthorized use may result in termination of the Merchant Account and legal action.
## ARTICLE 21 - OTHER TRADEMARKS
All trademarks, product names, and logos appearing in the Company materials or Services that are not owned by the Company are the property of their respective owners and may not be used without the applicable rights holder's permission. The Merchant agrees not to misrepresent any affiliation with such third parties.
## ARTICLE 22 - PROHIBITION OF MISUSE
The Merchant shall not misuse the Services, including by introducing malicious software, attempting unauthorized access to the Company's systems or infrastructure, engaging in denial-of-service attacks, or bypassing security mechanisms. Such conduct may constitute a criminal offense; the Company will report suspected breaches to law enforcement and cooperate with any investigation, and access to the Services will be immediately revoked. Any violation results in immediate termination of the Merchant Account.
## ARTICLE 23 - RESPONSIBILITY FOR FORESEEABLE LOSS
The Company shall not be liable for any loss or damage that is not foreseeable. A loss or damage is foreseeable if it is obvious that it will occur, or if both parties knew it might occur at the time these T\&Cs were entered into.
## ARTICLE 24 - LIMITATION OF LIABILITY
The Company does not exclude or limit liability where it would be unlawful to do so, including liability for death or personal injury caused by its negligence, or for fraud or fraudulent misrepresentation.
Subject to the foregoing, the Company's total aggregate liability for any claim arising from the use of the Services shall be limited to the total amount of service fees actually received by the Company from the Merchant during the six (6) months preceding the event giving rise to the claim. Under no circumstances shall the Company be liable for indirect, incidental, or consequential damages, loss of revenue, business or profits, or losses resulting from third-party failures, including financial partners or blockchain networks.
This limitation does not apply where the Company has acted with gross negligence or intentional non-performance, or where such limitation is not permitted under applicable law.
## ARTICLE 25 - LIMITATION OF LIABILITY FOR COMMERCIAL USE
To the fullest extent permitted by law, where the Merchant uses the Services for a commercial or business purpose, the Company shall not be liable for loss of profit, loss of business or revenue, business interruption, loss of business opportunity, or any indirect, incidental, or consequential damages.
## ARTICLE 26 - LIABILITY FOR TECHNOLOGICAL ATTACKS
The Company shall not be liable for loss or damage caused by viruses, malware, ransomware, phishing, or other technological attacks, or by security vulnerabilities affecting blockchain transactions, stablecoin payments, or third-party integrations. The Merchant is solely responsible for implementing adequate cybersecurity measures, including protecting the private keys and credentials associated with its payout wallet.
## ARTICLE 27 - LIABILITY FOR EVENTS OUTSIDE THE COMPANY'S CONTROL
The Company shall not be liable for any failure to perform or delay in providing the Services due to events beyond its reasonable control, including force majeure events, government or regulatory action, cybersecurity incidents affecting third-party providers, blockchain network failures, stablecoin depegging events, market disruptions, or failures of banking or payment infrastructure.
## ARTICLE 28 - INDEMNIFICATION; LIABILITY FOR BREACH OF T\&CS
If the Merchant breaches these T\&Cs, any applicable law, or misuses the Services, the Merchant agrees to compensate, defend, and hold the Company harmless against any losses, claims, damages, costs, or expenses (including legal fees) incurred by the Company as a result.
Without limiting the foregoing, the Merchant agrees to fully indemnify the Company for any claim, damage, liability, loss, cost, or expense arising out of or in connection with:
* the Merchant's Products, including their content, marketing, delivery, quality, performance, or non-compliance with applicable law or the Merchant's own representations;
* any actual or alleged infringement of third-party rights, including Intellectual Property rights, by the Merchant or its Products;
* any false, misleading, or incomplete information or representation made by the Merchant to Buyers or to the Company;
* any claim, investigation, fine, or enforcement action initiated by a Buyer, consumer protection authority, tax authority, or other regulator, to the extent resulting from the Merchant's non-compliance with applicable law, tax obligations, or these T\&Cs;
* disputes between the Merchant and a Buyer concerning the sale, delivery, performance, or refund of a Product;
* any breach of the Merchant's obligations under the Card Acceptance Agreement (Article 13), to the extent not already covered by Article 13.4.3.
This indemnification obligation survives termination of the Merchant Account and applies regardless of whether the underlying claim is ultimately successful.
## ARTICLE 29 - RELEASE
In the event of a dispute between the Merchant and any third party - including another Merchant, a wallet provider, a blockchain network operator, an off-ramp provider, or other infrastructure partner - arising from causes outside the Company's control, the Merchant agrees to release and hold the Company harmless from any related claims, damages, or losses, except to the extent such dispute arises directly from the Company's gross negligence, fraud, or wilful misconduct.
This Article does not limit the Company's own obligations as merchant of record towards Buyers, nor the Merchant's rights or the Company's obligations under Articles 4, 11, 12, and 13 in relation to transactions processed through the Service.
## ARTICLE 30 - DISCLAIMER OF WARRANTY
The Company provides the Services on an "as is," "where is," and "where available" basis, without any express, implied, or statutory warranty, including implied warranties of merchantability, fitness for a particular purpose, non-infringement, or uninterrupted availability. To the fullest extent permitted by law, the Merchant assumes all risk related to use of the Services.
Any templates, sample documents, guidance, or other materials provided by the Company via the Service are for general informational purposes only and do not constitute legal, tax, or compliance advice (see also Article 5).
## ARTICLE 31 - SERVICE AVAILABILITY
The Company will use commercially reasonable efforts to keep the Services available and operational, but does not guarantee uninterrupted or error-free availability, and may suspend, modify, restrict or discontinue all or part of the Services, including for scheduled maintenance or to address security incidents.
## ARTICLE 32 - MERCHANT RESPONSIBILITY
The Merchant is solely responsible for making the necessary arrangements to access the Services and for managing access permissions of any Authorized User. If the Company suspects unauthorized or fraudulent account access, it may refuse access to a third party and will notify the Merchant before or immediately after such access is blocked, unless doing so would violate security protocols or regulatory requirements.
## ARTICLE 33 - TERMINATION
### 33.1 Immediate Termination by the Company
The Company may immediately terminate the Merchant's access to the Service without prior notice where:
* the Merchant breaches these T\&Cs or applicable law, including misuse of the Services or non-compliance with tax or confidentiality obligations;
* the Company is required to do so by law, regulation, or a competent authority;
* there is reasonable suspicion of fraud, money laundering, or other unauthorized or illegal activity;
* the Merchant fails to pay fees, penalties, or other amounts due within the applicable period;
* continued use of the Service poses a risk to the security, stability, or integrity of the Service, the Company, or third parties;
* the conditions for immediate termination of card acceptance under Article 13.5.2 are met.
### 33.2 Termination with Notice
The Company may terminate a Merchant Account without cause, subject to at least thirty (30) days' prior notice. During that period, the Merchant must settle all outstanding payments and fulfil any pending transaction, refund, or tax obligation.
### 33.3 Consequences of Termination
Upon termination: the Merchant's right to access the Services ceases immediately; the Merchant Account may be deactivated; and the Merchant must cease all use of the Service and remove Company materials from its systems. Any remaining Payout will be processed in accordance with these T\&Cs; however, any rolling reserve or other withheld amount relating to card transactions will be retained for the period, and released in the manner, set out in Article 13.5.3 (minimum 120 days from the last processed transaction, longer where required), and any amount owed under Article 28 or Article 13.3.4 may be deducted before release. Provisions which by their nature should survive termination (including Articles 10, 12, 13.3.4, 13.5.3, 16, 23–29 and 33.4) remain in effect.
### 33.4 Post-Termination Actions
The Company retains the right to pursue legal remedies for a Merchant's breach of these T\&Cs, including damages and injunctive relief.
### 33.5 Termination by the Merchant
The Merchant may request voluntary termination of its Merchant Account at any time by contacting Customer Support, subject to the fulfilment of outstanding obligations. The Merchant may not request termination to avoid legal action, a regulatory investigation, or outstanding liabilities. If the Merchant attempts to close its account during an active investigation, the Company may temporarily withhold Payouts until the investigation concludes and may continue pursuing outstanding fees, disputes, or compliance matters after account closure. The Merchant remains responsible for unpaid fees, chargebacks, or legal obligations incurred before termination.
## ARTICLE 34 - TRANSFER AND ASSIGNMENT
The Merchant may not transfer, assign, mortgage, subcontract, or otherwise deal with its rights or obligations under these T\&Cs without the Company's prior written consent. The Company may transfer, assign, or novate these T\&Cs or any right or obligation under them at any time without the Merchant's consent. This does not affect the Merchant's right to close its Merchant Account under Article 33.
## ARTICLE 35 - PARTIES TO THE AGREEMENT
This agreement is solely between the Company and the Merchant. No third party has the right to enforce any provision of this agreement, except as explicitly stated herein. Neither party needs a third party's consent to modify, update, terminate, enforce, or waive any provision of these T\&Cs.
## ARTICLE 36 - PERSONAL DATA & PRIVACY POLICY
The Company's Privacy Policy governs the processing of personal data provided by the Merchant and is accessible at: Privacy Policy. The Privacy Policy, including the Company's Cookie Policy, is an integral part of these T\&Cs. By using the Services, the Merchant consents to the processing of its personal data and confirms that the data provided is accurate.
## ARTICLE 37 - CHANGES TO THE AGREEMENT
The Company may amend these T\&Cs by providing at least thirty (30) days' prior written notice via email or through the Application or Website. If the Merchant disagrees with the changes, it may terminate the agreement by written notice during the notice period, as described in Article 33. If the Merchant does not object, the updated T\&Cs apply from the effective date specified in the notice.
The Company may amend these T\&Cs without the 30-day notice where: the change is required by law; the change benefits the Merchant; the change introduces new services or functionalities without altering the existing contractual relationship; or the change does not reduce the Merchant's rights or increase its obligations. Changes to exchange rates take effect immediately without prior notice, and the Merchant may not dispute such adjustments.
## ARTICLE 38 - ENTIRE AGREEMENT
These T\&Cs, together with the Buyer Terms (to the extent relevant to the Merchant's obligations), any signed commercial or pricing agreement, and the Privacy Policy, constitute the entire agreement between the Company and the Merchant and supersede all prior agreements, written or oral, on the same subject matter. In the event of a conflict between a signed commercial agreement and these T\&Cs, these T\&Cs shall prevail on all matters other than pricing.
## ARTICLE 39 - SEVERABILITY
Each provision of these T\&Cs operates independently. If any provision is found invalid, unlawful, or unenforceable, the remaining provisions shall continue in full force and effect.
## ARTICLE 40 - ENFORCEMENT
The Company's failure to enforce any right under these T\&Cs does not waive its right to enforce it later. Any delay in requiring the Merchant to fulfil an obligation does not prevent the Company from taking enforcement action later.
## ARTICLE 41 - CLAIMS & CUSTOMER RELATIONS SERVICE
The Merchant may contact the Company's Customer Relations Service to report difficulties or submit complaints related to the Application, Website, or Services. Contact: [contact@suby.fi](mailto:contact@suby.fi)
## ARTICLE 42 - MEDIATION
The Merchant has the right to seek mediation in the event of a dispute with the Company. Mediation is a voluntary, confidential process facilitated by an impartial third-party mediator. The Merchant should contact the Customer Relations Service at [contact@suby.fi](mailto:contact@suby.fi) with a brief description of the dispute and the desired resolution. Both parties agree to participate in good faith; mediation costs are shared equally unless otherwise agreed. If mediation fails, the Merchant retains the right to pursue legal remedies. As the Merchant is not a consumer under the French Consumer Code, the Company is not legally required to appoint a designated mediator.
## ARTICLE 43 - APPLICABLE LAW
These T\&Cs are governed by and interpreted in accordance with French law.
## ARTICLE 44 - JURISDICTION
In the event of a dispute relating to the interpretation or execution of these T\&Cs, the parties will first attempt to resolve the matter amicably. If no resolution is reached within three (3) months, the dispute shall be referred to the Commercial Court of Paris, or any competent jurisdiction within the Paris Court of Appeal. This jurisdiction clause applies to summary proceedings, incidental claims, multiple defendants, and third-party notices, and to all disputes regardless of the payment method used. Any conflicting jurisdiction clause in the Merchant's own documents shall not apply.
## ARTICLE 45 - EFFECTIVE DATE
These T\&Cs (Merchant of Record version, full revision) are effective as of September 18, 2026 and supersede the previous version dated September 10, 2026.
# Terms & Conditions - PayFac
Source: https://docs.suby.fi/v3-beta/docs/legal/terms-and-conditions-PayFac
## PREAMBLE
These Terms and Conditions (hereinafter the "T\&Cs") apply: (i) to the conditions of access and use of the website "[www.suby.fi](http://www.suby.fi)" (hereinafter the "Site" or the "Website"), the "Application", and any API developed and owned by the "Company" (as defined below); (ii) to the conditions of access and use of the "Services" (as defined below); and, more generally, (iii) to any interaction a "User" or "Merchant" (as defined below) may have with the Company, its affiliates, or any third party when using the Site, the Application, an API or the Services.
The Site is operated by the Company. In connection with the Services, the Company acts as a payment facilitator and technical service provider enabling the Merchant to accept payments from Buyers for the Merchant's own Products, sold by the Merchant in its own name and on its own account, as further described in Article 4 below. The Company is not a party to the sale of the Product and does not act as merchant of record. A Merchant must accept and fully comply with these T\&Cs and the Privacy Policy before using the Services, an API or consulting the Site and the Application.
The preamble is a fundamental and binding component of the T\&Cs. Unless explicitly stated otherwise, the lists contained within the T\&Cs shall not be construed as restrictive or limiting in any way.
Capitalized terms have the meanings given to them in the Glossary below.
## GLOSSARY
API: Means any application programming interface provided by the Company.
Application: Means the mobile and/or web application software through which the Company offers its Services, including the data supplied with the software and the associated media.
Authorized User: Means a natural person operating or accessing a Merchant Account on behalf of a business using the Services.
Buyer: Means a natural person or legal entity who purchases a Product from a Merchant via the Service.
Company: Means Suby, a simplified joint-stock company (SAS) with a capital of 1,000 euros, having its registered office at Bureau 326, 59 rue de Ponthieu, 75008 Paris (France), registered under SIREN 990739302 (hereinafter the "Company", "Suby" or "we").
Intellectual Property: Means (i) rights in, and in relation to, any trademarks, logos, patents, registered designs, design rights, copyright and related rights, moral rights, databases, domain names, utility models, and including registrations and applications for, and renewals or extensions of, such rights, and similar or equivalent rights in any part of the world; (ii) rights in the nature of unfair competition rights and to sue for passing off and past infringement; and (iii) trade secrets, confidentiality and other proprietary rights, including know-how and other technical information.
Merchant / User: Means any natural person or legal entity that holds a Merchant Account and sells Products to Buyers, in its own name and on its own account, via the Service.
Merchant Account: Means the account created by an Authorized User on the Site in order to access and use the Services.
Merchant Terms of Sale: Means the terms and conditions governing the sale of Products by the Merchant to Buyers, drafted, published and made legally responsible for by the Merchant, and displayed at or before checkout in accordance with Article 4.3.
Net Proceeds: Means the gross amount collected from a Buyer for a card or alternative-payment-method transaction, less applicable transaction fees, network fees, reserves, and any other deduction expressly provided for in these T\&Cs or required under applicable card scheme rules.
Payment Facilitator (PF): Means the role in which the Company enables Merchant acceptance of card and alternative payment methods by leveraging the payment facilitator / platform programs of its acquiring partners, onboarding the Merchant as a sub-merchant within each such acquiring partner's own regulatory and contractual framework, as described in Article 13.
Payout: Means the net amount payable by the Company to the Merchant for transactions processed through the Service, after deduction of applicable service fees, taxes, refunds, chargebacks, reserves and any other amounts permitted under these T\&Cs.
Privacy Policy: Means the privacy policy of the Company which sets out the terms on which it processes personal data. By using the Services, the User consents to such processing and confirms that all data provided is accurate. The Privacy Policy is available at: Privacy Policy.
Product: Means any product or service sold by a Merchant to Buyers via the Service, including but not limited to digital goods, software as a service (SaaS), online content, physical goods and non-digital services.
Services: Means the payment facilitation service together with all other products, features, technologies or functions offered by the Company on its Website, Application or via its API.
Site / Website: Has the meaning given in the Preamble.
T\&Cs: Means these terms and conditions, including any annexes and referenced policies.
## ARTICLE 1 - USER AND MERCHANT ELIGIBILITY
The use of the Company's Services is exclusively reserved for commercial entities. Personal use for individual, non-commercial purposes is expressly prohibited.
Access to the Services is limited to Authorized Users who have been duly authorized by their respective businesses to act on their behalf. Authorized Users must provide the Company with valid credentials to confirm their binding authority when required. Failure to provide satisfactory proof of such authority may result in denial of access to the Services.
All Authorized Users must be at least 18 years of age. By using the Services, a User affirms that they are 18 years or older and possess the legal capacity to enter into a binding contract.
The Merchant represents and warrants that it is properly registered as a business or self-employed person under applicable law, holds all licenses, authorizations and registrations required to sell its Products, and is solely and fully responsible, as seller of record, for all aspects of the sale of the Products it offers via the Service.
## ARTICLE 2 - MERCHANT ACCOUNT
To access and use the Services, a User must create a Merchant Account and provide all requested business and identity details. The Merchant Account type and associated obligations depend on whether the Merchant operates as:
* A merchant selling digital products or services (SaaS, subscriptions, online content); or
* A merchant selling physical products or non-digital services (e-commerce, freelance work, logistics-based businesses).
### 2.1 Account Information & Verification
* All information provided to the Company must be complete, accurate and truthful at all times.
* The Merchant is responsible for updating its information whenever changes occur, including changes to its country of establishment, tax residency, VAT or other tax identification numbers, and legal status.
* The Company may request additional supporting documents at any time to verify compliance or satisfy its own regulatory obligations.
* Failure to provide accurate information may result in suspension or termination of access to the Merchant Account, and in withholding of Payouts.
### 2.2 Security & Responsibility
* The Merchant is solely responsible for safeguarding its Merchant Account credentials, including login details, API keys, or authentication methods.
* Where the Merchant Account is linked to a self-custodial wallet used to receive Payouts, the Merchant assumes full responsibility for securing access to that wallet.
* The Company is not liable for losses resulting from unauthorized access to the Merchant Account, incorrect payout wallet addresses, or mishandling of funds by the Merchant.
* Any suspected unauthorized use must be reported immediately to the Company.
### 2.3 Specific Responsibilities for Each Merchant Type
Merchants selling physical products (e-commerce, logistics-based) must:
* Maintain accurate inventory levels to prevent overselling;
* Handle logistics, shipping and returns of the Product at their own cost;
* Comply, as seller of record, with all applicable consumer protection laws relating to the sale, including pre-contractual information, withdrawal rights, and warranties.
Merchants selling digital products (SaaS, online content, software) must:
* Publish and maintain their own Merchant Terms of Sale, including refund eligibility periods, in accordance with Article 4.3;
* Ensure such Merchant Terms of Sale are displayed to the Buyer before checkout.
### 2.4 Account Access & Updates
Access to the Merchant Account is provided via email notifications; the Merchant must ensure the security of its email credentials. The Company retains sole discretion to modify or terminate Merchant Account requirements or any aspect of the Services. Continued use of the Services after any such modification constitutes the Merchant's acceptance of the updated requirements.
The main functions of the Service - including the ability to publish checkout sessions for Products, process transactions, or receive Payouts - will not become active until the Merchant has successfully completed and been approved through the verification process described in Article 6.
## ARTICLE 3 - MERCHANT ACCOUNT SECURITY
### 3.1 General Security Obligations
* Use one-time passwords (OTP) sent via email for authentication purposes.
* Immediately report any unauthorized access attempts to the Company.
* Ensure the security of the email account used for OTP verification and Merchant Account access.
### 3.2 Merchant Payout Method
The Merchant must designate, via the Merchant Account, its preferred Payout method: (i) a bank account for Payouts in fiat currency; or (ii) a self-custodial wallet address for Payouts in supported stablecoins. The Merchant may change its designated Payout method at any time via the Merchant Account, subject to any verification requirements applicable to the new method.
This payout mechanism operates independently from the Company's role as payment facilitator described in Article 4: the Company collects and processes payment from the Buyer on the Merchant's behalf, and separately executes Payouts to the Merchant's designated bank account or wallet, net of the amounts described in Article 11.
The Merchant is solely responsible for providing valid and correct bank account details or payout wallet address, as applicable, and for updating them as needed. Prior to withdrawal, funds corresponding to the Merchant's Suby Balance are held by the Company's Custody Partner in accordance with Article 16; neither the Company nor the Merchant has access to the private keys controlling those funds. Once a Payout has been executed to the Merchant's designated bank account or self-custodial wallet address, the Merchant is fully responsible for securing access to it, including any associated private keys where applicable. Where the Merchant elects to receive Payouts by bank transfer, the Company processes such Payouts via its banking or payment partners in accordance with standard bank transfer rails and timelines; the Company is not liable for delays or errors caused by the Merchant's bank or intermediary financial institutions. The Company cannot reverse, recover, or redirect a Payout once it has been executed to the designated bank account or wallet. In the event of an incorrect bank account or payout wallet address, a compromised Merchant wallet, or loss of wallet or bank account access, the Company cannot assist in recovering the funds beyond what its banking partners may reasonably support for bank-transfer Payouts.
### 3.3 Email & Device Security
* The Merchant must ensure the security of its email account, as it serves as the platform's authentication method.
* If the Merchant's email is compromised, it must notify the Company immediately.
* The Merchant must keep its browser and operating system up to date, including the latest security patches and antivirus software.
### 3.4 Prohibited Security Risks
To prevent unauthorized access, the Merchant must not:
* Share Merchant Account credentials, API keys, or payout wallet access with third parties;
* Allow remote access to its devices unless necessary for technical support;
* Use autofill features that store passwords in the browser;
* Attempt to bypass, disable, or interfere with two-factor authentication (2FA).
### 3.5 Liability Disclaimer
The Merchant is responsible for securing its own systems, including computers, software, and mobile devices used to access the Services. The Company does not guarantee that the Services will be free from bugs, malware, or cyber threats; the Merchant must implement adequate cybersecurity measures on its end.
## ARTICLE 4 - DESCRIPTION OF THE SERVICE; ROLES OF THE PARTIES
The Service enables the Merchant to sell its own Products to Buyers, in the Merchant's own name and on the Merchant's own account, via the Merchant's own website or other sales channel. Purchases are completed through the checkout solution provided by the Company, whether hosted by the Company or embedded on the Merchant's website, where the payment transaction is technically processed.
In this setup, the Company does not act as merchant of record, does not purchase or resell the Product, and is not a party to the sale contract between the Merchant and the Buyer. The Company's role is limited to enabling and processing the payment transaction as a payment facilitator, and to providing related administrative and technical services described below. The responsibilities of the Parties towards each other are set out below.
### 4.1 The Company is responsible for:
* providing the technical infrastructure (hosted checkout, API, or embedded integration) enabling the Merchant to accept payment from the Buyer;
* processing the payment transaction as payment facilitator, in accordance with Article 13;
* issuing a payment confirmation to the Buyer evidencing that payment has been made, which does not constitute a sales invoice or receipt for the Product;
* providing related administrative services, such as fraud prevention, technical dispute-management tooling, and merchant fee processing;
* settling the resulting Payout to the Merchant in accordance with Article 11.
### 4.2 The Merchant remains solely responsible for:
* selling the Product to the Buyer, in its own name and on its own account, as the sole seller of record;
* issuing any invoice, sales receipt, or equivalent document to the Buyer required under applicable law for the sale of the Product;
* calculating, collecting, declaring and remitting any applicable sales tax, VAT or other indirect tax associated with the sale of the Product, based on the Buyer's location and applicable tax law, as further described in Article 10;
* providing, delivering and ensuring access to the Product to the Buyer;
* ensuring that the Product performs as described and complies with applicable laws and regulations;
* ensuring that the Product does not infringe any third-party rights, including Intellectual Property rights;
* determining refund eligibility for the Product and instructing the Company accordingly under Article 12;
* managing all Buyer-facing customer service and post-sale support relating to the Product;
* fulfilling any consumer rights or remedies enforceable by the Buyer in relation to the Product, including withdrawal rights, legal warranties and product liability;
* publishing and maintaining Merchant Terms of Sale in accordance with Article 4.3;
* ensuring it is properly registered as a business under applicable law and reporting and paying all applicable direct and indirect taxes on its sales and on Payouts received, as further described in Article 10.
The Merchant remains, at all times, solely responsible for the nature, legality, availability, quality, performance, and tax treatment of its Products. The Company does not develop, test, host, maintain, sell, resell, or otherwise take title to the Product.
### 4.3 Buyer information
The Merchant shall clearly display its own Merchant Terms of Sale to the Buyer before checkout, including the identity of the Merchant as seller, refund and cancellation policy, and any other information required by applicable consumer protection law. The Merchant shall ensure that Buyers are clearly informed that the Merchant is the seller of the Product and that the Company (Suby) solely processes the payment as payment facilitator. In the event of any conflict between the Merchant Terms of Sale and these T\&Cs regarding the payment process, these T\&Cs shall prevail on payment-related matters; the Merchant Terms of Sale shall prevail on all matters relating to the sale of the Product itself.
## ARTICLE 5 - DISCLAIMERS
The Company acts solely as a payment facilitator and technical service provider. The Company is not a party to, and assumes no responsibility for, the sale contract between the Merchant and the Buyer. The Parties agree that, as between the Company and the Merchant:
* the Merchant is the sole seller of record and is solely responsible for the content, quality, delivery, legality, and compliance of its Products, including all applicable indirect and direct taxes;
* the Company shall not be deemed to assume any of the Merchant's obligations towards the Buyer, including delivery of the Product, invoicing, provision of support, compliance with consumer protection laws, or the accuracy and legality of Product information;
* the Company shall not be deemed to create, own, control, review, or endorse any Product offered by the Merchant, and assumes no responsibility for its legality, functionality, accuracy, performance, or compliance with applicable law or Buyer expectations.
While the Company facilitates the technical processing of refunds and chargebacks as part of payment handling (Article 12), the Merchant remains solely responsible for determining refund eligibility, handling return requests, and resolving the underlying dispute with the Buyer regarding the Product itself.
Any template, sample document, guidance, or other material provided by the Company via the Service (including any sample Merchant Terms of Sale) is for general informational purposes only and does not constitute legal, tax, or compliance advice. The Merchant is solely responsible for ensuring that its business, Products, Merchant Terms of Sale, and operations comply with all applicable laws and regulations.
## ARTICLE 6 - MERCHANT VERIFICATION AND COMPLIANCE
To comply with applicable laws and regulations, the Company requires all Merchants to undergo a verification process before accessing the payment-related functions of the Service. This process may include identity verification, anti-money laundering (AML) screening, and other compliance (KYC/KYB) checks.
The Merchant agrees to provide accurate and complete information as requested, including details regarding its legal entity, ownership structure, authorized representatives, business activities, and jurisdiction, and to keep this information up to date.
The Company may request additional information or documentation at any time, whether during onboarding or throughout the Merchant's use of the Service, and may engage third-party providers to carry out verification and compliance tasks.
Failure to provide required information or documentation, or providing false or misleading information, may result in suspension or termination of access to the Service, withholding of Payouts, or other action deemed appropriate by the Company.
The main payment-related functions of the Service - publishing checkout sessions, processing transactions, or receiving Payouts - will not become active until verification has been successfully completed and approved.
## ARTICLE 7 - USE OF THE SERVICE; PROHIBITED USE
The Service is intended for Merchants who wish to sell Products to Buyers using the Service's features as described on the Website. Using the Service for any other purpose is not permitted.
The Company may restrict the availability of the Service to Merchants or Buyers located in certain countries or territories. The relevant list is published on the Website and may be updated from time to time; the Service may not be used to offer Products to Buyers located in such countries or territories.
The Merchant shall not offer, via the Service, any Product included on the Company's prohibited or restricted products and merchant category (MCC) list, published and maintained on the Website and referenced in the Card Acceptance Agreement (Article 13.4). This list is incorporated by reference into these T\&Cs and may be updated by the Company from time to time to reflect card scheme rules, acquirer requirements, or applicable law.
Without limiting any of the Merchant's other obligations, the Merchant shall not, and shall not allow any Authorized User to:
* transfer the Merchant Account to anyone else without the Company's permission;
* use the Service for any unlawful, obscene, or immoral purpose;
* submit false or misleading information;
* engage in fraudulent, illegal, or abusive behaviour;
* offer Products subject to licensing, authorization or registration requirements (including but not limited to financial services, gambling, or medical services) or included on the prohibited products list referenced above;
* attempt to gain unauthorized access to, or interfere with, the security or infrastructure of the Service;
* upload or transmit malicious code, or use any device or routine that could disrupt the proper functioning of the Service.
The Company may screen Merchant content submitted via the Service and may remove, disable, or reject any content that conflicts with these T\&Cs, at its sole discretion and without prior notice.
## ARTICLE 8 - FEES AND PAYMENTS FOR THE SERVICE
As payment facilitator, the Company is entitled to a service fee for each transaction processed through the Service. This fee compensates the Company for payment processing infrastructure, fraud prevention, dispute-management tooling, and related administrative services. The service fee consists of:
* a percentage-based commission on the gross transaction amount; and
* a fixed fee per transaction,
as specified in the pricing schedule made available to the Merchant via the Website, the Merchant Account, or the applicable commercial agreement. Applicable fees, together with any amounts described in Articles 11, 12 and 13, are deducted before the Payout is made to the Merchant.
Fees may vary depending on the payment method used by the Buyer (fiat or supported cryptocurrency), the Merchant's plan, transaction volume, risk profile, and operational or infrastructure costs. Card and alternative-payment-method transaction pricing is further specified in the Card Acceptance Agreement (Article 13.6).
Where no separate commercial agreement covering pricing has been signed by the Parties, or such an agreement does not address a given fee, the Company's standard default pricing shall apply automatically, namely a transaction fee of 2.9% of the gross transaction amount plus a fixed amount of \$0.30 per transaction, together with the ancillary fees set out in Article 13.6. Continued use of the Services by the Merchant in the absence of a signed pricing agreement constitutes acceptance of these default rates. The Company may update its default pricing with at least fifteen (15) days' written notice to the Merchant.
The Company may access various additional features that are free of charge or paid; descriptions and pricing for such features are available on the Website or within the Service. By using a paid feature, the Merchant agrees to pay the applicable fee. The Company may update its pricing or change the availability of features (including making a free feature paid) at any time, subject to at least fifteen (15) days' prior notice via the Website, the Service, or email. The Merchant will not be charged for a newly priced feature without being notified and given the opportunity to opt out by discontinuing use of that feature.
### Confidentiality of Pricing
The fee structure agreed with a Merchant is confidential commercial information. The Merchant agrees not to disclose such pricing terms to third parties without the Company's prior written consent. Breach of this obligation may result in suspension or termination of the Merchant Account.
## ARTICLE 9 - SELF-BILLING OF MERCHANT PAYOUTS
The Company shall issue self-billed invoices on behalf of the Merchant to document the amounts payable by the Company to the Merchant under these T\&Cs. The Merchant agrees not to issue separate invoices to the Company for these Payouts.
The Company shall make self-billed invoices available to the Merchant via the Merchant Account or another agreed method. The Merchant undertakes to review each invoice and to notify the Company in writing of any objection within three (3) business days; in the absence of such notice, the invoice is deemed accepted.
The Merchant shall promptly inform the Company of any change to its tax registration status, invoicing details, or other information affecting the accuracy of self-billed invoices. Where the Merchant is VAT-registered, or otherwise qualifies as a taxable person for VAT purposes, the Merchant confirms that no VAT shall be applied to Payouts received from the Company and acknowledges that such Payouts may be subject to a reverse-charge mechanism where applicable.
For the avoidance of doubt, these self-billed invoices document only the Company's own service fees and the resulting Payout owed to the Merchant; they do not constitute, and shall not be treated as, an invoice for the sale of the Product to the Buyer, which remains the Merchant's sole responsibility under Article 10.
## ARTICLE 10 - TAXES AND INVOICING
### 10.1 Indirect taxes - the Merchant's sole responsibility
Unlike in a merchant-of-record arrangement, the Company does not calculate, collect, or remit any sales tax, VAT, or other indirect tax on the sale of the Product. The Merchant is solely and fully responsible for determining its own tax obligations, including registering for VAT or sales tax in any jurisdiction where required, calculating the correct amount of tax due on each sale, collecting such tax from the Buyer as part of the sale price, and remitting it to the competent tax authorities.
The Company shall issue a payment confirmation to the Buyer evidencing that payment has been made via the Service; this document does not constitute a sales invoice or tax receipt for the Product and does not include, calculate, or represent any indirect tax. The Merchant is solely responsible for issuing to the Buyer any invoice or tax document required under applicable law.
The Company will make available to the Merchant, via the Merchant Account, regular transaction records reflecting gross amounts received, fees deducted, and Payout amounts. These records are intended for reconciliation and informational purposes only and do not replace, and shall not be relied upon as, the Merchant's own tax records or filings.
### 10.2 Direct taxes - the Merchant's responsibility
The Merchant remains solely responsible for the declaration, payment, and compliance with all direct taxes applicable to its business, including income tax, corporate tax, and any self-employment contributions on Payouts received from the Company, which the Merchant shall treat as taxable business income in accordance with applicable tax law.
Payouts made by the Company to the Merchant constitute the net proceeds of the Merchant's own sale of Products to Buyers, collected by the Company on the Merchant's behalf as payment facilitator, and shall not be treated as royalties, licence fees, or payments for the use of Intellectual Property.
### 10.3 No tax advice
The Company does not provide tax, legal, or accounting advice, and does not determine or verify the Merchant's tax obligations on any sale. The Merchant is strongly encouraged to consult a qualified tax advisor regarding its indirect and direct tax obligations in every jurisdiction where it sells Products.
### 10.4 Records and cooperation
The Merchant agrees to retain records relating to Products sold via the Service and to cooperate with the Company in providing reasonable documentation for tax or audit purposes upon request.
### 10.5 Consequences of non-compliance
Failure by the Merchant to register for, collect, or remit applicable indirect taxes, or to comply with its tax obligations generally, may result in suspension or termination of access to the Service, withholding of Payouts, or reporting to competent authorities where legally required. The Company shall not be liable for any penalties, interest, back-taxes, or other consequences arising from the Merchant's non-compliance with applicable tax law, and the Merchant shall indemnify the Company in accordance with Article 28 for any resulting claim against the Company.
## ARTICLE 11 - PAYMENTS AND PAYOUTS
Amounts owed to the Merchant are held pending withdrawal in accordance with Article 16. The Company collects payment from Buyers for transactions processed through the Service, on the Merchant's behalf as payment facilitator, in fiat currency via the Company's regulated acquiring and payment partners (see Article 13 for card and alternative payment methods), and/or in supported cryptocurrencies processed on-chain. After deducting applicable service fees, taxes, refunds, chargebacks, reserves, and other amounts permitted under these T\&Cs, the Company settles the resulting Payout to the Merchant using the payout method designated under Article 3.2: (i) by bank transfer in fiat currency to the Merchant's designated bank account; or (ii) by converting the relevant amount into supported stablecoins and transferring it on-chain to the Merchant's designated self-custodial wallet address.
The Merchant is solely responsible for ensuring that its designated bank account details or payout wallet address are accurate and up to date. Payouts, once executed to the designated bank account or wallet, are irreversible; the Company cannot recover, reverse, or redirect funds once sent, and is not liable for losses arising from incorrect payout details or from the Merchant's mismanagement of its bank account or wallet.
If the Merchant elects to convert stablecoins received as a Payout into fiat currency, such conversion must be performed via third-party off-ramp providers. Exchange rates, conversion fees, availability, and execution are determined exclusively by such providers, and the Company bears no responsibility for exchange rate volatility, conversion outcomes, or losses resulting from off-ramping.
Payouts are executed in accordance with the schedule, thresholds, and process published on the Website or made available via the Merchant Account, and, for card transactions, in accordance with the settlement timing set out in Article 13.3. The Company may modify the Payout schedule, thresholds, and related procedures at any time, with such changes taking effect upon publication.
The Company may withhold or delay a Payout to: (i) comply with applicable law or a regulatory obligation; (ii) investigate a suspected fraudulent, illegal, or prohibited transaction; (iii) maintain a reserve for potential chargebacks or refunds as described in Article 12.4 and Article 13.3; or (iv) enforce these T\&Cs.
The Company may deduct or offset any amount owed by the Merchant to the Company - including fees, refunds, chargebacks, penalties, or indemnification claims under Article 28 - from current or future Payouts, or from any reserve held under Article 12.4 or Article 13.3. The Merchant is responsible for all costs associated with receiving a Payout, including any network or blockchain fees.
## ARTICLE 12 - REFUNDS AND CHARGEBACKS
All refunds and chargebacks related to transactions processed through the Service are technically handled via the Service. The Merchant shall not process or accept any refund or return independently for such transactions outside the Service, and remains solely responsible for determining refund eligibility for its Products, as it is the seller of record.
The Merchant must request any refund via the functionality provided in the Merchant Account. The Company will technically process such requests upon Merchant instruction, in accordance with the Service's procedures and applicable law.
Notwithstanding the above, the Company may, at its sole discretion, issue a refund to a Buyer without prior instruction from the Merchant where:
* required by law or applicable consumer protection regulation;
* mandated by a card scheme, acquiring partner, or regulatory authority;
* due to a technical error, duplicate payment, or manifest mistake; or
* there is a suspected fraudulent payment or a payment dispute.
The Merchant shall reimburse the Company for any amount refunded under the preceding paragraph, unless the refund is caused solely by the Company's gross negligence or intentional non-performance.
In the event of a chargeback initiated by a Buyer, the Company will notify the Merchant and may request supporting documentation to contest the claim; the Merchant shall cooperate promptly and in good faith and remains solely responsible for the merits of the underlying dispute relating to the Product. The Merchant bears full financial responsibility for chargebacks related to its Products, including the original transaction amount and any associated fees or penalties, unless the chargeback is solely attributable to an error by the Company.
The Company may deduct amounts related to refunds or chargebacks from the Merchant's Payouts, from the reserve described below, or may invoice the Merchant directly.
### 12.4 Rolling reserve (general)
Where a Merchant's chargeback rate, refund rate, or overall risk profile so warrants, the Company may withhold a rolling reserve from the Merchant's Payouts to cover potential chargebacks, refunds, or other financial exposure. The applicable reserve percentage and holding period are determined by the Company based on the Merchant's risk profile (including its business model, MCC, chargeback and refund history, and transaction volume), as communicated to the Merchant via the Merchant Account or the applicable commercial agreement, and may be adjusted by the Company from time to time to reflect changes in the Merchant's risk profile.
As a general threshold applicable across payment methods, if the Merchant's monthly chargeback rate or refund rate exceeds one percent (1.0%) of transactions, the Company may increase the reserve percentage, extend the reserve holding period, or suspend Payouts until the Merchant's risk exposure is resolved. Reserved amounts are released on a first-in-first-out basis at the end of the holding period applicable at the time each amount was withheld, unless applied against outstanding chargebacks, refunds, or other amounts owed by the Merchant, or unless a longer period is required under applicable law, card scheme rules, or acquirer requirements.
## ARTICLE 13 - CARD ACCEPTANCE AGREEMENT (PAYMENT FACILITATOR MODEL)
This Article constitutes the card acceptance agreement between the Company and the Merchant, incorporating the applicable rules of the card schemes (including Visa and Mastercard) and any other supported alternative payment method ("APM") network. By accepting these T\&Cs, the Merchant acknowledges and agrees to all terms set out in this Article, and specifically acknowledges that the Company acts as Payment Facilitator (PF), onboarding the Merchant as a sub-merchant under the Company's master merchant agreements with its acquiring bank(s) and in accordance with the card schemes' payment facilitator/aggregator programs. Pricing applicable to card and APM acceptance is defined exclusively in the commercial agreement or pricing schedule signed separately between the Parties, or, in the absence thereof, in the default pricing referenced in Article 8 and Article 13.6. All other conditions of card acceptance - including billable events, reserves, settlement, risk, compliance, dispute management, and termination - are governed exclusively by this Article 13.
### 13.1 Role, structure and accepted payment methods
* The Company acts as payment facilitator, not as merchant of record, by leveraging the payment facilitator / platform programs made available by its acquiring partners. Under this model, the Merchant is onboarded as a sub-merchant directly within the technical and contractual framework of the relevant acquiring partner, under that acquiring partner's own card scheme registration and regulatory authorization. The Company may use different acquiring partners depending on the Merchant's region, currency, risk profile, or business model; the specific acquiring partner(s) applicable to the Merchant's transactions will be communicated via the Merchant Account. The Merchant is disclosed to the relevant acquiring partner(s) and, where required by card scheme rules, to the card schemes themselves, as the true seller of the underlying Product (sub-merchant disclosure).
* The Company charges the Buyer on the Merchant's behalf, receives funds from its acquiring partners, and remits Net Proceeds to the Merchant as a Payout, subject to the deductions, reserves and suspension rights set out in this Article.
* "Net Proceeds" means the gross amount collected from Buyers, less applicable transaction fees, network fees, reserves, and any other deduction expressly provided for in these T\&Cs or required by applicable card scheme rules.
* The Merchant shall not process, refund, or initiate chargebacks directly with acquirers or card schemes. All such actions must be initiated exclusively through the Company, which retains sole discretion to initiate, approve, decline, or process refunds, dispute responses, and chargeback management on the Merchant's behalf, in accordance with card scheme rules, acquirer requirements, risk controls, or consumer protection standards.
* Card and APM acceptance is limited to methods explicitly approved by the Company, including its hosted checkout, direct API integration, mobile-optimized flows, or approved partner-embedded pages. The Merchant shall not implement unapproved or standalone integrations, and shall not enter into a separate, direct merchant agreement with an acquirer or card scheme for the same activity without the Company's prior written consent.
* The Company retains sole discretion to approve or decline any merchant category code (MCC), payment flow, transaction currency, or Buyer country of residence for onboarding as a sub-merchant. Only approved categories and jurisdictions will be activated.
* Nothing in this Article grants the Merchant the right to act as a payment facilitator, payment service provider, or agent of the Company. The Merchant remains fully independent and responsible for its own licensing obligations and its relationships with its own Buyers.
Accepted payment methods (non-exhaustive, subject to change): card networks - Visa, Mastercard (credit and debit), with 3-D Secure 2.0 where applicable; alternative payment methods - as made available on the Website from time to time. The Company may modify, add, or remove specific payment methods and will, where possible, inform the Merchant in advance; it may suspend or disable a payment method immediately where required by card schemes, acquiring partners, applicable law, or risk controls.
### 13.2 Billable events and transaction controls
The following events are billable under these T\&Cs: authorization attempt; capture or settlement; refund; chargeback initiation; account updater or token usage; and dispute-prevention tools and services (including RDR, Ethoca, Verifi or equivalent).
The maximum transaction value is defined dynamically by the Company based on business model, MCC, or payment method. The Merchant shall not attempt to submit a transaction exceeding the defined limit without the Company's prior written consent. The Company does not impose a default daily per-card transaction limit unless required by applicable network rules or specific anti-fraud requirements; volume caps may be introduced dynamically based on risk profile or compliance needs and will be communicated to the Merchant in writing where applicable. Certain billable events may trigger pass-through fees imposed by card schemes, acquiring partners, or related service providers (including account updater services, tokenization services, and similar network fees); such pass-through fees may be deducted from Net Proceeds or applied against the rolling reserve, and will be itemized in reporting where possible.
### 13.3 Reserve and settlement
This section governs the rolling reserve, settlement timing, the Merchant's financial responsibility, and the escalation protocol applicable to a Merchant Debit Balance.
### 13.3.1 Rolling reserve
A rolling reserve may be withheld on card transactions, at a percentage determined by the Company based on the Merchant's risk profile in accordance with Article 12.4. The reserve may be used by the Company at any time to fund Buyer refunds or mitigate transaction-related financial exposure, including but not limited to chargebacks, fraud, or insolvency. Net Proceeds are generally settled on a T+3 to T+5 business-day basis.
### 13.3.2 Release of the reserve
The rolling reserve is released on a first-in-first-out basis at the end of the holding period applicable at the time of withholding, as determined under Article 12.4, unless used to cover refund obligations or otherwise offset, withheld, or deferred where required by card scheme rules, acquiring partner requirements, or applicable law, or to cover pending or reasonably anticipated chargebacks, refunds, disputes, cancellations, fraud losses, or network fines. Any utilized portion of the reserve is automatically replenished from future transaction proceeds. Reserve payouts follow the standard settlement cycle and are disbursed within three (3) to five (5) business days of their respective release date.
### 13.3.3 Chargeback and refund rate threshold
For the purposes of this Article, "chargeback rate" and "refund rate" mean the chargeback-to-transaction ratio and the refund-to-transaction ratio, calculated in accordance with the applicable card scheme rules (or, if not otherwise specified, the total number of first chargebacks or refunds received in a calendar month divided by the total number of captured transactions in the same month, expressed as a percentage).
If the Merchant's monthly chargeback rate or refund rate exceeds 1.0% (or any lower threshold required by applicable card scheme rules or acquiring partner requirements), the Company may suspend all payouts and delay settlement until the risk exposure is resolved. The overall compliance, remediation, and termination framework is set out in Article 13.3.4 below. The Company will notify the Merchant promptly after exercising such right, except where immediate action is required to comply with card scheme obligations or to prevent active fraud.
### 13.3.4 Financial responsibility and debit balance protocol
(a) Financial responsibility. The Merchant is solely and fully responsible to the Company for any financial exposure arising from transactions processed through the Company's infrastructure, including but not limited to chargebacks, refunds, fraud losses, and card scheme fines, regardless of origin or cause. The rolling reserve constitutes only a partial guarantee and does not cap the Merchant's total liability.
(b) Debit balance. Where the rolling reserve is insufficient to cover financial exposure, the unpaid amount constitutes a legally binding debt owed by the Merchant to the Company (the "Debit Balance"). The Company will notify the Merchant in writing of any Debit Balance, including a breakdown of the underlying transactions and the amount owed.
(c) Automatic recovery. The Company will recover any Debit Balance automatically by: (i) deducting it from the Merchant's future settlement proceeds; and/or (ii) drawing on the rolling reserve. If these T\&Cs are terminated or the Merchant Account is closed before the Debit Balance is fully recovered, the remaining balance becomes immediately due and legally binding, and the Company reserves the right to pursue recovery through any available legal means.
(d) Escalation protocol: Step 1 - Notification: the Company notifies the Merchant in writing of the Debit Balance or risk event, with all necessary details, and makes its payments team available to coordinate remediation. Step 2 - Activation of chargeback protection: if the chargeback rate increases and exposes the Company to risk, the Company will activate chargeback protection programs (RDR, Ethoca alerts, Verifi or equivalent); costs of these programs, as invoiced by the relevant providers, are passed through to the Merchant and deducted from Net Proceeds or applied against the rolling reserve, with full transparency as to costs and covered transactions. Step 3 - Full account suspension: if the Debit Balance remains unresolved, or suspension rights are triggered, the Company may suspend all processing and settlement activity; the Merchant will be informed in writing of the triggering event and the conditions required to restore service.
(e) Survival. The Merchant's financial obligations under this section survive termination of these T\&Cs. Any Debit Balance not recovered before or upon termination remains immediately due and legally binding.
(f) Account closure with a debit balance. If the Merchant requests account closure or ceases processing activity while a Debit Balance exists or is reasonably anticipated (including pending disputes, chargebacks, or refunds), all such amounts become immediately due. The Company may offset any amount owed by the Merchant against any amount payable to the Merchant, including future settlements, reserves (released or not), and any other funds held or processed by the Company. The Merchant shall reimburse the Company's reasonable collection costs, including external legal fees where applicable.
### 13.4 Risk, compliance, and network rules
### 13.4.1 General compliance with network rules
* All activity must comply with Visa, Mastercard, and other applicable network rules, including those relating to chargebacks, MCC classifications, and permitted countries.
* The Company retains full discretion regarding which jurisdictions, currencies, and use cases may be supported. Transactions from unauthorized countries or business models will be blocked or refunded.
* The Merchant shall not contract separately or independently with card schemes for services provided under these T\&Cs.
### 13.4.2 Chargeback threshold and remediation
If the Merchant's chargeback rate exceeds 1.0% in a calendar month (or a lower threshold required by applicable card scheme rules or acquiring partner requirements), the Company may: suspend settlements; increase reserves; impose additional fraud controls; or suspend card processing and require a formal remediation plan.
If the chargeback rate remains above 1.0% for two consecutive months, the Company may terminate card acceptance services with immediate effect. Unless immediate action is required by card scheme rules or to prevent active fraud, the Company will provide written notice and a remediation period of at least seven (7) calendar days before exercising its termination rights under this section.
### 13.4.3 Indemnification
The Merchant shall indemnify and hold the Company harmless from direct losses, card scheme penalties, or damages resulting from intentional fraud, gross negligence, or material violations of card scheme rules committed by the Merchant. This indemnification does not apply to routine operational issues, unintentional errors, or chargebacks arising from valid Buyer disputes. This section is supplementary to, and does not limit, any other indemnification or allocation of liability set out elsewhere in these T\&Cs, including Article 28.
### 13.4.4 Dispute prevention services
The Company may, at its discretion or where required by card schemes or acquiring partners, activate dispute prevention or resolution programs (including but not limited to Rapid Dispute Resolution (RDR), Ethoca Alerts, Verifi, or equivalent). Such activation may occur if the Company identifies a significant increase in fraud or chargeback indicators, or where card schemes or acquiring partners require it. The Company will inform the Merchant before or immediately after activation. Costs charged by program providers are passed through to the Merchant and deducted from Net Proceeds or applied against the reserve, with full transparency as to amounts and covered transactions.
### 13.4.5 Chargeback dispute process
Upon receiving a chargeback claim, the Company will promptly notify the Merchant, providing the reason code, transaction reference, chargeback amount, and available dispute information. The Merchant has seven (7) calendar days from notification to submit evidence for representment. If no evidence is submitted within this period, the Company may accept the chargeback without recourse for the Merchant. The Company will assess representment eligibility based on the evidence provided and applicable card scheme rules; the final decision to pursue representment rests with the Company.
### 13.4.6 PCI-DSS and data security
* The Merchant must at all times comply with the Payment Card Industry Data Security Standard (PCI-DSS) requirements applicable to its role and transaction volumes.
* The Merchant shall not store, process, or transmit cardholder data (including full card numbers, CVV/CVC codes, or PINs) unless strictly necessary and fully compliant with PCI-DSS.
* In the event of an actual or suspected data breach involving cardholder data, the Merchant must notify the Company immediately and fully cooperate with any forensic investigation. All costs related to the forensic investigation, card scheme fines, or card reissuance attributable to the Merchant shall be borne solely by the Merchant.
### 13.4.7 Sub-merchant disclosure
The Merchant acknowledges and agrees that, as required under the payment facilitator / platform program of the relevant acquiring partner, and under applicable Visa and Mastercard payment facilitator/aggregator program rules, the Company is required to disclose to the relevant acquiring partner(s), and, where applicable, to the relevant card scheme(s) via such acquiring partner(s), certain identifying information about the Merchant as sub-merchant - including but not limited to its legal name, trading name, business address, MCC, and transaction volume - as a condition of the Merchant's onboarding under that acquiring partner's payment facilitator / platform program and of the Merchant's continued ability to accept card payments through the Service.
### 13.5 Duration and termination of card acceptance
### 13.5.1 Standard termination
Card acceptance services may be terminated by either Party upon thirty (30) days' written notice.
### 13.5.2 Immediate termination
The Company may terminate card acceptance services with immediate effect, without notice or penalty, in the event of: a material breach of these T\&Cs by the Merchant; the Merchant's chargeback or fraud rate reaching the termination conditions set out in Article 13.4.2, subject to the notice and remediation process described therein, unless immediate action is required by card scheme rules, acquiring partners, or applicable law; the Merchant's insolvency, liquidation, or cessation of business; or a termination requirement imposed by card scheme rules, acquiring partners, or applicable law.
### 13.5.3 Reserve retention after termination
Upon termination, transaction processing ceases immediately. Rolling reserves and any other withheld or pending amounts may be retained by the Company for a minimum period of one hundred and twenty (120) days following the date of the last processed transaction, and longer if required by card scheme rules, acquiring partner requirements, applicable law, or the need to cover pending chargebacks, refunds, disputes, cancellations, fraud losses, or network fines.
Chargebacks received after termination will be deducted from retained amounts. If retained amounts are insufficient, the outstanding balance constitutes a debt owed by the Merchant to the Company, recoverable in accordance with Article 13.3.4. Any remaining balance, net of outstanding obligations, will be released following final reconciliation.
### 13.6 Pricing - reference to the commercial agreement
Pricing applicable to card acceptance services (transaction fees, chargeback processing fees, card scheme fees, and any other applicable charge) is defined exclusively in the commercial agreement or pricing schedule signed separately between the Company and the Merchant. All other conditions relating to card acceptance are governed by this Article 13.
For reference only, and subject to an individual agreement, standard default pricing is as follows: cards: 2.9% + \$0.30 per transaction, chargeback processing \$25 per Visa dispute, \$50 per Mastercard dispute. These rates may vary depending on payment method, region, and risk profile.
## ARTICLE 14 - REGULATORY QUALIFICATION
The Parties expressly acknowledge and agree that:
* the Company does not act as merchant of record and is not a party to the sale of the Product; the Merchant is at all times the sole seller of record;
* the Company acts as a technical payment facilitator, enabling the Merchant to accept card and alternative payment method transactions as a disclosed sub-merchant under the Company's agreements with its acquiring partners, in accordance with Article 13;
* the Company enables the Merchant to accept payments by leveraging the payment facilitator / platform programs of its regulated acquiring partners, each of which holds its own authorization as a payment service provider or acquiring institution under applicable law; the Company does not itself hold a separate payment institution license and relies on the scope of activity permitted to it under its commercial and technical relationship with each such acquiring partner;
* the Company does not itself hold or control the private keys to funds corresponding to the Merchant's Suby Balance, which are held by a regulated third-party Custody Partner in accordance with Article 16, pending withdrawal by the Merchant;
* any conversion between fiat currency and stablecoins is performed by the Company for its own account.
This Article still requires payment-law counsel review before publication, though the risk is narrower than in a fully independent PF model. Because the Company relies on each acquiring partner's own PSP/EMI authorization rather than holding its own payment institution license, the central question is no longer whether the Company needs its own license, but whether the Company's specific role - technical orchestration, sub-merchant aggregation, and holding of the Suby Balance ahead of withdrawal - stays within the technical-service-provider / commercial-agent boundary of PSD2 (see PSD2 Article 3), or crosses into the Company itself executing the payment service. This depends on the precise terms of each acquiring partner agreement and should be confirmed contract by contract, particularly where multiple acquiring partners are used with potentially different program terms.
## ARTICLE 15 - THIRD-PARTY MATERIALS
Certain features of the Website, Application, or Services may enable the Merchant to access or interact with information, products, services or content provided by third parties ("Third-Party Materials"), including embedded content, hyperlinks, APIs, off-ramp providers, or external integrations.
The Company does not control, endorse, or assume responsibility for any Third-Party Materials, including their accuracy, legality, or security, and may block, restrict, or remove access to them at its sole discretion. The Merchant engages with Third-Party Materials at its own risk and subject to the relevant third party's own terms.
## ARTICLE 16 - CUSTODY OF FUNDS AND MERCHANT BALANCE
Amounts payable to the Merchant following a sale are reflected as a balance in the Merchant Account (the "Suby Balance") pending withdrawal by the Merchant. The Suby Balance is a record of the amount owed by the Company to the Merchant; it does not constitute a deposit, e-money, or a custodial digital asset account held by the Company.
The Company does not hold, control, or have access to the private keys, seed phrases, or wallet credentials associated with any wallet used in connection with the Services, whether the Merchant's own withdrawal destination or otherwise. Funds corresponding to the Suby Balance are held, pending withdrawal, by a regulated third-party custodian or payment institution engaged by the Company (the "Custody Partner"). Neither the Company nor the Merchant has direct access to the private keys or credentials controlling the funds held by the Custody Partner; access and release of funds are governed by the Company's agreement with the Custody Partner and are triggered by a withdrawal instruction validly submitted by the Merchant via the Merchant Account.
Upon a withdrawal request, the Company instructs the Custody Partner to release the corresponding funds, which are transferred directly to the bank account or self-custodial wallet address designated by the Merchant under Article 3.2. From the point such funds are received at the Merchant's designated bank account or wallet, the Merchant assumes full and sole responsibility for their custody and security, in accordance with Article 3.2.
The Company shall not be liable for any act, omission, insolvency, security incident, or operational failure of the Custody Partner, except to the extent caused by the Company's own gross negligence or wilful misconduct in selecting or instructing the Custody Partner. The Company does not guarantee the availability, solvency, or continued operation of any Custody Partner and may change its Custody Partner at any time, with notice to the Merchant where the change materially affects withdrawal timelines or processes.
For the avoidance of doubt, this Article governs the holding of funds between collection from the Buyer and withdrawal by the Merchant. The Company's role in collecting funds from Buyers as payment facilitator is governed by Articles 4, 11 and 13.
## ARTICLE 17 - NO FIDUCIARY DUTIES
These T\&Cs do not create or impose any fiduciary duty on the Company. The Company does not act as a trustee, agent, or financial custodian for the Merchant. To the fullest extent permitted by law, the Merchant acknowledges that the Company's only obligations towards it are those expressly set out in these T\&Cs, and any potential fiduciary obligation is irrevocably disclaimed and waived.
## ARTICLE 18 - INTELLECTUAL PROPERTY
All rights, title, and interest in and to any software, services, and Intellectual Property developed, provided, or made available by the Company or its affiliates - including the Application, Website, API, developer tools, sample source code, documentation, and the technology and proprietary algorithms used in the Company's payment infrastructure - remain the exclusive property of the Company and its licensors. All Company materials and Services are protected by Intellectual Property laws and international treaties.
Subject to these T\&Cs, the Company grants the Merchant a worldwide, non-exclusive, non-transferable, non-sublicensable and revocable licence to access and use the Service for its intended purpose, for internal business use only, for as long as these T\&Cs remain in force.
## ARTICLE 19 - RESTRICTIONS ON USE OF COMPANY MATERIALS
Unless authorized in writing by the Company, the Merchant shall not: use or exploit Company materials for unauthorized commercial purposes; sell, sublicense, lease, rent, assign, or otherwise transfer the Services or Company materials to a third party; remove or alter any trademark or Intellectual Property notice; modify, copy, adapt, or create derivative works of Company software or materials; or reverse-engineer, disassemble, or decompile any Company software.
Unauthorized use may result in immediate termination of the Merchant Account and legal action, including for damages and injunctive relief.
## ARTICLE 20 - COMPANY TRADEMARKS
A non-exhaustive list of Company trademarks includes "SUBY" and any other business or service name, logo, sign, graphic, page header, button icon, or script belonging to the Company or its licensors ("Company Trademarks").
Unless authorized in writing, the Merchant may not copy, imitate, modify, or use the Company Trademarks in a way that misrepresents affiliation, implies endorsement, creates confusion, or disparages the Company. The Merchant may use Company-provided HTML logos solely to direct traffic to the Company's official Services, without modifying or distorting them. Unauthorized use may result in termination of the Merchant Account and legal action.
## ARTICLE 21 - OTHER TRADEMARKS
All trademarks, product names, and logos appearing in the Company materials or Services that are not owned by the Company are the property of their respective owners and may not be used without the applicable rights holder's permission. The Merchant agrees not to misrepresent any affiliation with such third parties.
## ARTICLE 22 - PROHIBITION OF MISUSE
The Merchant shall not misuse the Services, including by introducing malicious software, attempting unauthorized access to the Company's systems or infrastructure, engaging in denial-of-service attacks, or bypassing security mechanisms. Such conduct may constitute a criminal offense; the Company will report suspected breaches to law enforcement and cooperate with any investigation, and access to the Services will be immediately revoked. Any violation results in immediate termination of the Merchant Account.
## ARTICLE 23 - RESPONSIBILITY FOR FORESEEABLE LOSS
The Company shall not be liable for any loss or damage that is not foreseeable. A loss or damage is foreseeable if it is obvious that it will occur, or if both parties knew it might occur at the time these T\&Cs were entered into.
## ARTICLE 24 - LIMITATION OF LIABILITY
The Company does not exclude or limit liability where it would be unlawful to do so, including liability for death or personal injury caused by its negligence, or for fraud or fraudulent misrepresentation.
Subject to the foregoing, the Company's total aggregate liability for any claim arising from the use of the Services shall be limited to the total amount of service fees actually received by the Company from the Merchant during the six (6) months preceding the event giving rise to the claim. Under no circumstances shall the Company be liable for indirect, incidental, or consequential damages, loss of revenue, business or profits, or losses resulting from third-party failures, including financial partners or blockchain networks.
This limitation does not apply where the Company has acted with gross negligence or intentional non-performance, or where such limitation is not permitted under applicable law.
## ARTICLE 25 - LIMITATION OF LIABILITY FOR COMMERCIAL USE
To the fullest extent permitted by law, where the Merchant uses the Services for a commercial or business purpose, the Company shall not be liable for loss of profit, loss of business or revenue, business interruption, loss of business opportunity, or any indirect, incidental, or consequential damages.
## ARTICLE 26 - LIABILITY FOR TECHNOLOGICAL ATTACKS
The Company shall not be liable for loss or damage caused by viruses, malware, ransomware, phishing, or other technological attacks, or by security vulnerabilities affecting blockchain transactions, stablecoin payments, or third-party integrations. The Merchant is solely responsible for implementing adequate cybersecurity measures, including protecting the private keys and credentials associated with its payout wallet.
## ARTICLE 27 - LIABILITY FOR EVENTS OUTSIDE THE COMPANY'S CONTROL
The Company shall not be liable for any failure to perform or delay in providing the Services due to events beyond its reasonable control, including force majeure events, government or regulatory action, cybersecurity incidents affecting third-party providers, blockchain network failures, stablecoin depegging events, market disruptions, or failures of banking or payment infrastructure.
## ARTICLE 28 - INDEMNIFICATION; LIABILITY FOR BREACH OF T\&CS
If the Merchant breaches these T\&Cs, any applicable law, or misuses the Services, the Merchant agrees to compensate, defend, and hold the Company harmless against any losses, claims, damages, costs, or expenses (including legal fees) incurred by the Company as a result.
Without limiting the foregoing, the Merchant agrees to fully indemnify the Company for any claim, damage, liability, loss, cost, or expense arising out of or in connection with:
* the Merchant's Products, including their content, marketing, delivery, quality, performance, or non-compliance with applicable law or the Merchant's own representations, the Merchant being at all times the sole seller of record;
* the Merchant's Merchant Terms of Sale, including their accuracy, legality, and compliance with applicable consumer protection law;
* the Merchant's failure to calculate, collect, declare or remit any applicable indirect or direct tax on the sale of its Products;
* any actual or alleged infringement of third-party rights, including Intellectual Property rights, by the Merchant or its Products;
* any false, misleading, or incomplete information or representation made by the Merchant to Buyers or to the Company, including in connection with its sub-merchant disclosure under Article 13.4.7;
* any claim, investigation, fine, or enforcement action initiated by a Buyer, consumer protection authority, tax authority, card scheme, acquiring partner, or other regulator, to the extent resulting from the Merchant's non-compliance with applicable law, tax obligations, or these T\&Cs;
* disputes between the Merchant and a Buyer concerning the sale, delivery, performance, or refund of a Product;
* any breach of the Merchant's obligations under the Card Acceptance Agreement (Article 13), to the extent not already covered by Article 13.4.3.
This indemnification obligation survives termination of the Merchant Account and applies regardless of whether the underlying claim is ultimately successful.
## ARTICLE 29 - RELEASE
In the event of a dispute between the Merchant and any third party - including another Merchant, a wallet provider, a blockchain network operator, an off-ramp provider, or other infrastructure partner - arising from causes outside the Company's control, the Merchant agrees to release and hold the Company harmless from any related claims, damages, or losses, except to the extent such dispute arises directly from the Company's gross negligence, fraud, or wilful misconduct.
This Article does not limit the Company's own obligations as payment facilitator towards Buyers, nor the Merchant's rights or the Company's obligations under Articles 4, 11, 12, and 13 in relation to transactions processed through the Service.
## ARTICLE 30 - DISCLAIMER OF WARRANTY
The Company provides the Services on an "as is," "where is," and "where available" basis, without any express, implied, or statutory warranty, including implied warranties of merchantability, fitness for a particular purpose, non-infringement, or uninterrupted availability. To the fullest extent permitted by law, the Merchant assumes all risk related to use of the Services.
Any templates, sample documents, guidance, or other materials provided by the Company via the Service are for general informational purposes only and do not constitute legal, tax, or compliance advice (see also Article 5).
## ARTICLE 31 - SERVICE AVAILABILITY
The Company will use commercially reasonable efforts to keep the Services available and operational, but does not guarantee uninterrupted or error-free availability, and may suspend, modify, restrict or discontinue all or part of the Services, including for scheduled maintenance or to address security incidents.
## ARTICLE 32 - MERCHANT RESPONSIBILITY
The Merchant is solely responsible for making the necessary arrangements to access the Services and for managing access permissions of any Authorized User. If the Company suspects unauthorized or fraudulent account access, it may refuse access to a third party and will notify the Merchant before or immediately after such access is blocked, unless doing so would violate security protocols or regulatory requirements.
## ARTICLE 33 - TERMINATION
### 33.1 Immediate Termination by the Company
The Company may immediately terminate the Merchant's access to the Service without prior notice where:
* the Merchant breaches these T\&Cs or applicable law, including misuse of the Services or non-compliance with tax or confidentiality obligations;
* the Company is required to do so by law, regulation, or a competent authority;
* there is reasonable suspicion of fraud, money laundering, or other unauthorized or illegal activity;
* the Merchant fails to pay fees, penalties, or other amounts due within the applicable period;
* continued use of the Service poses a risk to the security, stability, or integrity of the Service, the Company, or third parties;
* the conditions for immediate termination of card acceptance under Article 13.5.2 are met.
### 33.2 Termination with Notice
The Company may terminate a Merchant Account without cause, subject to at least thirty (30) days' prior notice. During that period, the Merchant must settle all outstanding payments and fulfil any pending transaction, refund, or tax obligation.
### 33.3 Consequences of Termination
Upon termination: the Merchant's right to access the Services ceases immediately; the Merchant Account may be deactivated; and the Merchant must cease all use of the Service and remove Company materials from its systems. Any remaining Payout will be processed in accordance with these T\&Cs; however, any rolling reserve or other withheld amount relating to card transactions will be retained for the period, and released in the manner, set out in Article 13.5.3 (minimum 120 days from the last processed transaction, longer where required), and any amount owed under Article 28 or Article 13.3.4 may be deducted before release. Provisions which by their nature should survive termination (including Articles 10, 12, 13.3.4, 13.5.3, 16, 23–29 and 33.4) remain in effect.
### 33.4 Post-Termination Actions
The Company retains the right to pursue legal remedies for a Merchant's breach of these T\&Cs, including damages and injunctive relief.
### 33.5 Termination by the Merchant
The Merchant may request voluntary termination of its Merchant Account at any time by contacting Customer Support, subject to the fulfilment of outstanding obligations. The Merchant may not request termination to avoid legal action, a regulatory investigation, or outstanding liabilities. If the Merchant attempts to close its account during an active investigation, the Company may temporarily withhold Payouts until the investigation concludes and may continue pursuing outstanding fees, disputes, or compliance matters after account closure. The Merchant remains responsible for unpaid fees, chargebacks, or legal obligations incurred before termination.
## ARTICLE 34 - TRANSFER AND ASSIGNMENT
The Merchant may not transfer, assign, mortgage, subcontract, or otherwise deal with its rights or obligations under these T\&Cs without the Company's prior written consent. The Company may transfer, assign, or novate these T\&Cs or any right or obligation under them at any time without the Merchant's consent. This does not affect the Merchant's right to close its Merchant Account under Article 33.
## ARTICLE 35 - PARTIES TO THE AGREEMENT
This agreement is solely between the Company and the Merchant. No third party has the right to enforce any provision of this agreement, except as explicitly stated herein. Neither party needs a third party's consent to modify, update, terminate, enforce, or waive any provision of these T\&Cs.
## ARTICLE 36 - PERSONAL DATA & PRIVACY POLICY
The Company's Privacy Policy governs the processing of personal data provided by the Merchant and is accessible at: Privacy Policy. The Privacy Policy, including the Company's Cookie Policy, is an integral part of these T\&Cs. By using the Services, the Merchant consents to the processing of its personal data and confirms that the data provided is accurate.
## ARTICLE 37 - CHANGES TO THE AGREEMENT
The Company may amend these T\&Cs by providing at least thirty (30) days' prior written notice via email or through the Application or Website. If the Merchant disagrees with the changes, it may terminate the agreement by written notice during the notice period, as described in Article 33. If the Merchant does not object, the updated T\&Cs apply from the effective date specified in the notice.
The Company may amend these T\&Cs without the 30-day notice where: the change is required by law; the change benefits the Merchant; the change introduces new services or functionalities without altering the existing contractual relationship; or the change does not reduce the Merchant's rights or increase its obligations. Changes to exchange rates take effect immediately without prior notice, and the Merchant may not dispute such adjustments.
## ARTICLE 38 - ENTIRE AGREEMENT
These T\&Cs, together with the Merchant's own Merchant Terms of Sale (to the extent relevant to the payment process), any signed commercial or pricing agreement, and the Privacy Policy, constitute the entire agreement between the Company and the Merchant and supersede all prior agreements, written or oral, on the same subject matter. In the event of a conflict between a signed commercial agreement and these T\&Cs, these T\&Cs shall prevail on all matters other than pricing. In the event of a conflict between the Merchant Terms of Sale and these T\&Cs, these T\&Cs shall prevail on all payment-related matters, and the Merchant Terms of Sale shall prevail on all matters relating to the sale of the Product itself.
## ARTICLE 39 - SEVERABILITY
Each provision of these T\&Cs operates independently. If any provision is found invalid, unlawful, or unenforceable, the remaining provisions shall continue in full force and effect.
## ARTICLE 40 - ENFORCEMENT
The Company's failure to enforce any right under these T\&Cs does not waive its right to enforce it later. Any delay in requiring the Merchant to fulfil an obligation does not prevent the Company from taking enforcement action later.
## ARTICLE 41 - CLAIMS & CUSTOMER RELATIONS SERVICE
The Merchant may contact the Company's Customer Relations Service to report difficulties or submit complaints related to the Application, Website, or Services. Contact: [contact@suby.fi](mailto:contact@suby.fi)
## ARTICLE 42 - MEDIATION
The Merchant has the right to seek mediation in the event of a dispute with the Company. Mediation is a voluntary, confidential process facilitated by an impartial third-party mediator. The Merchant should contact the Customer Relations Service at [contact@suby.fi](mailto:contact@suby.fi) with a brief description of the dispute and the desired resolution. Both parties agree to participate in good faith; mediation costs are shared equally unless otherwise agreed. If mediation fails, the Merchant retains the right to pursue legal remedies. As the Merchant is not a consumer under the French Consumer Code, the Company is not legally required to appoint a designated mediator.
## ARTICLE 43 - APPLICABLE LAW
These T\&Cs are governed by and interpreted in accordance with French law.
## ARTICLE 44 - JURISDICTION
In the event of a dispute relating to the interpretation or execution of these T\&Cs, the parties will first attempt to resolve the matter amicably. If no resolution is reached within three (3) months, the dispute shall be referred to the Commercial Court of Paris, or any competent jurisdiction within the Paris Court of Appeal. This jurisdiction clause applies to summary proceedings, incidental claims, multiple defendants, and third-party notices, and to all disputes regardless of the payment method used. Any conflicting jurisdiction clause in the Merchant's own documents shall not apply.
## ARTICLE 45 - EFFECTIVE DATE
These T\&Cs (Platform version, first release) are effective as of September 10, 2026.
# Terms & Conditions - Buyer
Source: https://docs.suby.fi/v3-beta/docs/legal/terms-and-conditions-buyer
Last updated: Oct 5, 2026
This version applies to orders confirmed from 5 October 2026.
## Preamble
These Terms and Conditions of Sale (the "T\&Cs") govern every purchase made by a consumer or non-professional ("you" or the "Customer") through the Suby checkout where Suby SAS ("Suby") acts as Merchant of Record. As Merchant of Record, Suby buys the products and services offered by the businesses that use its platform (the "Merchants") and resells them to the Customer in its own name and on its own account. Suby is therefore the seller and the Customer's contractual counterparty for the purchase, including for billing, payment, taxes, delivery, refunds, legal guarantees and disputes.
Merchants supply their products and services to Suby and deliver them, or provide access to them, on Suby's behalf, directly or through Suby's systems. They have no contractual relationship with the Customer in respect of the purchase. A Merchant's terms of use may govern how a product or service is used, but they cannot reduce the Customer's rights under these T\&Cs. If the Product page or the checkout shows a refund or money-back policy that is more favourable to the Customer, Suby honours it as seller, in addition to the Customer's statutory rights.
These T\&Cs apply to every purchase for which the checkout identifies Suby SAS as the seller before payment. They do not apply where the checkout identifies a Merchant as the seller, for example where a Merchant sells in its own name using Suby's checkout technology. They also do not apply to purchases paid in crypto-assets, as Suby does not accept crypto-assets as payment for sales it makes as Merchant of Record. In those cases, the Merchant's own terms of sale apply and Suby is not a party to the sale.
These T\&Cs are the "Buyer Terms" referred to in Suby's Merchant of Record terms for purchases made by consumers and non-professionals. They do not apply to purchases made for business purposes. They are available at checkout in a format that can be saved and printed. By confirming a purchase through the Suby checkout, the Customer accepts these T\&Cs. The version that applies to an order is the one accepted at checkout and attached to the Order Confirmation. It continues to govern that order, including any subscription, unless the Customer accepts a new version.
## Article 1. Company identification
* Suby SAS, a simplified joint-stock company with a share capital of €1,000
* Registered office: Bureau 326, 59 rue de Ponthieu, 75008 Paris, France
* Registered with the Paris Trade and Companies Register under number 990 739 302 (SIRET 990 739 302 00018)
* Intra-EU VAT number: FR81 990 739 302
* Email: [contact@suby.fi](mailto:contact@suby.fi)
* Telephone: +33 6 58 97 44 42
## Article 2. Products and services
The products and services sold through the Suby checkout (the "Products") may include digital content and files, licence keys, software and software-as-a-service, access to online communities and content (such as paid Discord or Telegram channels, newsletters and memberships), online services and, where applicable, physical goods. Suby resells each Product on the basis of the Merchant's specifications.
Before placing an order, the Customer is shown the essential characteristics of the Product, its price including all taxes, any delivery costs, the contract duration and, for subscriptions, the billing period. For digital content and services, the Customer is also shown the relevant functionality, compatibility and interoperability requirements.
As seller, Suby is liable to the Customer for the proper performance of the contract, including where the Product is delivered or provided by the Merchant or another third party (Article L221-15 of the French Consumer Code). Suby may seek recourse against the Merchant, but this never affects the Customer's rights. The Customer may contact Suby about any issue with a purchase, including conformity, delivery, refunds and warranty claims. Suby remains the Customer's point of contact and liaises with the Merchant as needed.
## Article 3. Ordering and checkout process
**3.1 Eligibility.** To place an order, the Customer must be at least 18 years old or have the permission of a parent or legal guardian, and must provide accurate information, including a valid email address and billing address.
**3.2 Placing an order.** An order may start on the Merchant's website, application or community. Once the Customer proceeds to payment, the order is handled through Suby's checkout, either hosted by Suby or embedded on the Merchant's website. The steps are as follows:
1. selection of the Product;
2. entry of the Customer's email address and billing details;
3. choice of payment method;
4. review of the order summary, including the Product, its price including all taxes and, for subscriptions, the billing period;
5. where applicable, the Customer's express request for immediate access to digital content or immediate performance of a service (Article 4);
6. confirmation of the order by clicking a button that clearly indicates an obligation to pay (for example "Pay now").
**3.3 Conclusion of the contract.** The contract between Suby and the Customer is concluded when the payment is successfully authorised. Suby issues receipts and invoices in its own name, and the Customer pays Suby as the seller.
**3.4 Order confirmation.** After payment, and in any event before delivery or the start of performance, Suby sends the Customer an email confirming the contract (the "Order Confirmation"). It states the Product, the price paid including all taxes and any delivery costs, the billing period and next renewal date for subscriptions, the transaction reference and the billing details. It attaches these T\&Cs as a PDF file together with the withdrawal form in Annex 1, contains the link to the withdrawal function described in Article 4.2 and, where applicable, confirms the Customer's express consent under Article 4.6. It also gives access to the Suby customer portal (customer.suby.fi), where the Customer can view purchases and manage subscriptions.
**3.5 Correction of errors.** Before confirming the order, the Customer can review the order summary and correct any input error by going back to the previous checkout steps. After confirmation, any question or correction should be sent to [contact@suby.fi](mailto:contact@suby.fi). This does not affect the right of withdrawal.
**3.6 Archiving.** Suby keeps a record of each order, including payment details, billing information and an order summary. For orders of €120 or more (or the equivalent amount in US dollars), Suby archives the contract for 10 years from its conclusion or, if delivery or performance takes place later, from that date (Articles L213-1, D213-1 and D213-2 of the French Consumer Code). The Customer may access the archived contract at any time by writing to [contact@suby.fi](mailto:contact@suby.fi).
**3.7 Language.** The contract can be concluded in French or in English.
## Article 4. Right of withdrawal
**4.1 Withdrawal period.** The Customer may withdraw from the contract within 14 days without giving any reason (Articles L221-18 et seq. of the French Consumer Code). The period runs:
* for services and for digital content not supplied on a tangible medium, from the day the contract is concluded;
* for physical goods, from the day the Customer, or a third party designated by the Customer other than the carrier, takes possession of the goods or, for several goods delivered separately, of the last item.
If the period ends on a Saturday, Sunday or public holiday, it is extended to the next working day.
**4.2 How to withdraw.** The Customer may withdraw free of charge using the "Withdraw from the contract here" function. Throughout the withdrawal period, this function is clearly displayed in the Suby customer portal (customer.suby.fi), which the Customer can reach without an account or password, including through a direct link in the Order Confirmation and in the footer of the Suby checkout. The Customer gives or confirms their name, the order concerned and the email address to which the acknowledgement should be sent, then clicks "Confirm withdrawal". The Customer may also send the form in Annex 1, or any other clear statement, to [contact@suby.fi](mailto:contact@suby.fi) or to Suby's postal address. Suby acknowledges receipt without delay by email, stating the content of the withdrawal and the date and time it was received. A withdrawal made within the period does not need Suby's approval.
**4.3 Refund.** Suby refunds all sums paid, including standard delivery costs and less any amount owed under Article 4.5, without undue delay and no later than 14 days after being informed of the withdrawal. For physical goods, Suby may withhold the refund until it has received the goods or proof that they have been sent back, whichever comes first. The refund is made using the original payment method, unless the Customer expressly agrees otherwise, and at no cost to the Customer.
**4.4 Return of physical goods.** The Customer must return the goods to the address given by Suby no later than 14 days after notifying the withdrawal. The direct cost of return is borne by the Customer, unless the Product page or the checkout states that Suby bears it. The Customer is only liable for any loss in value caused by handling the goods beyond what is necessary to establish their nature, characteristics and functioning.
**4.5 Services started during the withdrawal period.** This paragraph applies to services, including digital services such as software-as-a-service, online services and access to online communities (for example a paid Discord or Telegram channel or group). If the Customer expressly asks at checkout for the service to start before the end of the withdrawal period, the Customer is also asked to acknowledge that the right of withdrawal will be lost once the service has been fully performed. If the Customer then withdraws, they pay for the service provided up to the withdrawal, in proportion to the total price agreed (Article L221-25 of the French Consumer Code). The Customer owes nothing if Suby did not obtain this express request or did not inform the Customer before the order that this amount would be payable.
**4.6 Exceptions.** Under Article L221-28 of the French Consumer Code, the right of withdrawal does not apply to:
* digital content not supplied on a tangible medium (for example a downloadable file, or a licence key for downloadable software) whose supply has begun, where the Customer (a) gave prior express consent to immediate supply, (b) acknowledged losing the right of withdrawal, and (c) received confirmation of this consent in the Order Confirmation;
* services fully performed before the end of the withdrawal period, where performance began with the Customer's prior express consent and acknowledgement that the right of withdrawal would be lost once the service is fully performed;
* goods made to the Customer's specifications or clearly personalised;
* goods liable to deteriorate or expire rapidly;
* sealed goods unsealed after delivery that cannot be returned for health or hygiene reasons;
* sealed audio or video recordings or computer software unsealed after delivery.
Access to software-as-a-service, online services and online communities is a digital service, not digital content. The first exception therefore does not apply to it. The Customer keeps the right of withdrawal unless the service has been fully performed, and Article 4.5 applies if the Customer withdraws after asking for immediate access.
The Customer gives the express consent and acknowledgement described above by ticking a box, unticked by default, at checkout. If these conditions are not met, the Customer keeps the right of withdrawal and owes nothing for the digital content supplied or the service provided before withdrawing (Articles L221-25 and L221-26 of the French Consumer Code). The checkout states before the order whenever an exception applies to a Product.
## Article 5. Price and payment
**5.1 Price.** Prices are displayed at checkout including all applicable taxes (VAT or equivalent), calculated on the basis of the Customer's billing address. They are shown in euros for Customers located in France, and in euros or US dollars for other Customers. Any delivery costs are shown before the order is confirmed. Suby charges no fee for the use of any particular payment method.
**5.2 Payment methods.** The available payment methods are displayed at the start of the checkout. Depending on the Product and the Customer's location, they may include payment cards (Visa, Mastercard, American Express), Apple Pay, Google Pay, bank transfer or direct debit, and buy-now-pay-later solutions such as Klarna. Crypto-assets are not accepted for purchases governed by these T\&Cs. Card payments are processed by Suby's regulated payment partners and may require strong customer authentication (3-D Secure). Suby does not store full card numbers.
**5.3 Buy-now-pay-later.** Buy-now-pay-later, instalment and similar solutions are provided by a third party under its own terms, which the Customer accepts directly with that provider. Where such a solution is a credit agreement, the provider, not Suby, is the lender. If the Customer withdraws from the purchase, the related financing agreement ends automatically at no cost to the Customer (Article L221-27 of the French Consumer Code), and Suby makes the refund due under Article 4 through that provider.
**5.4 Receipts and bank statement.** All receipts and invoices are issued by Suby in its own name. For card payments, including through Apple Pay or Google Pay, the charge appears on the Customer's statement under a descriptor that includes the name "SUBY", which may be followed by the Merchant's brand (for example "SUBY\*BRAND").
**5.5 Third-party fees.** Fees charged by the Customer's bank, card issuer or payment provider, such as foreign exchange or international transaction fees, are not charged by Suby and remain the Customer's responsibility.
## Article 6. Subscriptions and recurring payments
**6.1 Billing.** Subscriptions are billed in advance for each billing period shown at checkout (for example weekly, monthly, quarterly, half-yearly or yearly). The price per period and the renewal date are shown before the order.
**6.2 Duration.** Subscriptions billed weekly or monthly are concluded for an indefinite period and may be cancelled at any time under Article 6.6. Subscriptions billed quarterly, half-yearly or yearly are concluded for a fixed term equal to the billing period and renew automatically for the same term unless cancelled under Article 6.6.
**6.3 Usage-based plans.** For usage-based plans, the unit price, the calculation method, any spending limit and the moments when charges are taken are shown before the order. Charges are taken at the end of each billing period and, where the checkout says so, when a usage threshold shown at checkout is reached or when the Customer buys a top-up. The Customer authorises Suby to take these charges from the saved payment method. Each receipt shows the usage and unit price on which the charge is based.
**6.4 Automatic payments.** For subscriptions paid by card or another automatic payment method, the Customer authorises Suby to charge the price of each new period to the saved payment method on the renewal date. The Customer must keep these payment details up to date in the customer portal. If a payment is declined, access may be suspended and Suby may retry the payment over the following 3 days. If the payment still fails, the subscription ends.
**6.5 Free trials.** Where a subscription starts with a free or discounted trial, the trial length and the price that applies afterwards are shown before the order. Unless the Customer cancels before the end of the trial, the subscription continues at that price.
**6.6 Cancellation.** The Customer may cancel a subscription at any time, free of charge, using the "Cancel your contract" function. It is directly accessible through the link in each payment receipt email, from the Suby checkout and from the Suby customer portal, without the Customer having to create an account. The Customer gives or confirms their name, email address and the subscription concerned, checks a summary page and confirms the cancellation. The Customer may also write to [contact@suby.fi](mailto:contact@suby.fi). Suby confirms the cancellation by email, stating the date it takes effect. The subscription ends at the end of the current billing period or, if the cancellation is made during a trial, at the end of the trial. Access remains active until that date and no further payment is taken, except, for usage-based plans, the charge for usage recorded up to that date. During the withdrawal period, the Customer may instead withdraw under Article 4 and be refunded under Article 4.3.
**6.7 Price changes.** For subscriptions without a fixed term, Suby may change the price for future billing periods only. It informs the Customer by email at least 30 days before the new price applies, stating the new price, the date from which it applies and the Customer's right to cancel. The Customer may cancel free of charge before that date, and the new price never applies to a period already paid. For fixed-term subscriptions, the price cannot change during the current term, and any new price for a renewal term is notified at least 30 days before the deadline for refusing the renewal.
**6.8 Renewal reminder.** For fixed-term subscriptions that renew automatically, Suby sends the Customer a dedicated email, no earlier than three months and no later than one month before the renewal date, reminding the Customer that they may choose not to renew. The email shows the deadline for refusing the renewal in a clearly visible box. Articles L215-1 to L215-3 and L241-3 of the French Consumer Code, which set out the Customer's rights if this reminder is not sent, are reproduced in Annex 3.
**6.9 Discontinuation.** If a subscription, or a Product paid in advance for a period, stops being provided before the end of that period for a reason not attributable to the Customer (for example because the Merchant discontinues it or a community is closed), Suby informs the Customer by email, in advance where possible, takes no further payment and refunds the unused part of the period on a pro rata basis within 14 days. This does not affect the Customer's other rights, including under Articles 8, 9 and 10.
## Article 7. Chargebacks and unauthorised payments
**7.1 Chargebacks.** A chargeback occurs when the Customer disputes a card payment with their bank. As Merchant of Record, Suby is the merchant in the chargeback process. Suby reviews each chargeback and may provide the payment provider with evidence such as the order details, proof of delivery or access, and consent records. Suby may contest a chargeback it considers unfounded, for example where the Product was delivered as described. While a chargeback is open, Suby may suspend the access linked to the disputed payment (for example a licence key, a community role or a subscription). If the chargeback is withdrawn or rejected, Suby restores that access and extends the current billing period by the length of the suspension. If the chargeback is upheld, Suby does not charge the amount again and any related subscription ends.
**7.2 Contact Suby first.** The Customer is encouraged to contact Suby at [contact@suby.fi](mailto:contact@suby.fi) before starting a chargeback, as most issues (non-delivery, duplicate charge, unwanted renewal) can be solved quickly with a refund. This is only a recommendation and does not limit the Customer's rights with their bank.
**7.3 Unauthorised payments.** If the Customer did not authorise a payment made by card (including through Apple Pay or Google Pay), bank transfer or direct debit, they should report it without undue delay to their bank or payment provider, within the time limit that applies to them (under French and EU rules, no later than 13 months after the debit date). That provider is responsible for refunding unauthorised payments under Articles L133-18 et seq. of the French Monetary and Financial Code or the equivalent rules of the Customer's country. For SEPA direct debits, the Customer may generally also ask their bank to refund an authorised debit within 8 weeks of the debit date (Articles L133-25 and L133-25-1 of the same Code). The Customer should also inform Suby, which will refund any amount it received without a valid order.
**7.4 Abuse.** Where Suby has evidence that a chargeback or refund request is fraudulent or made in bad faith, it may refuse future orders from that Customer.
## Article 8. Delivery
**8.1 Digital Products.** Unless the checkout states otherwise, digital content, download links, licence keys and access to online communities and services are made available immediately after payment. Depending on the Product, they are provided on the confirmation page, by email, in the Suby customer portal (where the Customer may need to claim them, for example by connecting a Discord or Telegram account or opening a single-use invite) or through the Merchant's platform. Access to a third-party platform such as Discord or Telegram may require an account on that platform, subject to its own terms. If the Customer has not given the express request described in Article 4.6, they keep the right of withdrawal and owe nothing for what was supplied before withdrawing.
**8.2 Physical goods.** The delivery method, timeframe and costs are shown before the order. If no date or timeframe is shown, the goods are delivered no later than 30 days after the contract is concluded. The risk of loss or damage passes to the Customer when the Customer, or a third party designated by the Customer other than the carrier proposed by Suby, takes physical possession of the goods.
**8.3 Late or failed delivery.** If a Product is not delivered or made available by the agreed date, the Customer may ask Suby, by email or any other durable medium, to deliver within a reasonable additional period. If Suby fails to do so, the Customer may terminate the contract. The Customer may terminate immediately if Suby refuses to deliver or if the delivery date was essential to the Customer. Suby then refunds all sums paid within 14 days of termination.
**8.4 Contact.** For any delivery question, including delays, non-delivery or delivery errors, the Customer should contact Suby at [contact@suby.fi](mailto:contact@suby.fi). Suby liaises with the Merchant or the carrier to resolve the issue.
## Article 9. Legal guarantees
As seller, Suby is responsible to the Customer for the legal guarantees below, whatever the outcome of its recourse against the Merchant. Claims can be sent to Suby SAS, Bureau 326, 59 rue de Ponthieu, 75008 Paris, France, by email to [contact@suby.fi](mailto:contact@suby.fi) or by telephone at +33 6 58 97 44 42. Suby handles the claim and liaises with the Merchant as needed. The information on legal guarantees required by Articles D211-2 to D211-4 of the French Consumer Code is set out in Annex 2.
**9.1 Physical goods.** Suby is liable for any lack of conformity that appears within 2 years of delivery (Articles L217-3 et seq. of the French Consumer Code). Defects appearing within that period are presumed to have existed at delivery (12 months for second-hand goods). The Customer may choose repair or replacement, free of charge, within 30 days of the request. Failing that, the Customer is entitled to a price reduction or to terminate the contract and be refunded.
**9.2 Digital content and services.** Suby is liable for any lack of conformity that appears within 2 years of supply for a one-off supply, or at any time during the supply period for continuous supply such as a subscription (Articles L224-25-12 et seq. of the French Consumer Code). The Customer is entitled to have the content or service brought into conformity or, failing that, to a price reduction or termination of the contract.
**9.3 Hidden defects.** The Customer may also claim under the guarantee against hidden defects (Articles 1641 et seq. of the French Civil Code) within 2 years of discovering the defect, and choose between terminating the sale with a refund or keeping the goods with a price reduction.
**9.4 Commercial guarantees.** Any commercial guarantee offered by a Merchant is described before the order and confirmed by email, naming the guarantor. It applies in addition to the legal guarantees and never replaces them. Any refund or money-back policy shown on the Product page or at checkout is a commercial guarantee that Suby honours as seller. Suby offers no other commercial guarantee of its own.
## Article 10. Liability
As seller, Suby is liable to the Customer for the proper performance of the contract and for the Products sold, in accordance with applicable law, including where the Products are delivered or provided by the Merchant or another third party. Suby may only be released from this liability, in whole or in part, by proving that the failure is attributable to the Customer, to the unforeseeable and insurmountable act of a third party unconnected with the contract, or to force majeure (Article L221-15 of the French Consumer Code).
Nothing in these T\&Cs limits or excludes any liability or consumer right that cannot be limited or excluded under applicable law.
Suby is not responsible for services it does not supply and that the Customer uses alongside a Product, such as the Customer's own device, internet access or account on a third-party platform.
The Customer is responsible for keeping their payment credentials and email account confidential and secure. Unauthorised payments are dealt with in Article 7.
## Article 11. Force majeure
Suby is not liable for any failure or delay caused by an event of force majeure within the meaning of Article 1218 of the French Civil Code, that is, an event beyond its control that could not reasonably have been foreseen when the contract was concluded and whose effects cannot be avoided by appropriate measures. Depending on the circumstances, this may include natural disasters, war, terrorism, government restrictions, large-scale internet or telecommunications outages, or the failure of a payment network outside Suby's control.
If the impediment is temporary, performance is suspended for its duration, unless the delay justifies termination of the contract. If it is permanent, the contract is terminated and the Customer is refunded any amount paid for goods or services not delivered.
## Article 12. Intellectual property
All content, trademarks, logos, software, APIs, checkout pages, interfaces and technologies developed or made available by Suby are protected by intellectual property laws and remain the exclusive property of Suby or its licensors. The Customer may not reproduce, copy, modify, reverse-engineer or otherwise exploit them without Suby's prior written authorisation.
Products supplied in digital form may be protected by intellectual property rights held by the Merchant or its licensors. Unless the checkout, or the Merchant's terms of use made available before the order, provide otherwise, the purchase grants the Customer a personal, non-exclusive and non-transferable right to use them for private purposes, without prejudice to any right the Customer has under mandatory law. The Customer owns the physical goods purchased, and any intellectual property rights in them remain with their holders.
## Article 13. Prohibited uses and restricted territories
The Customer agrees not to use Suby's checkout or services for any unlawful, fraudulent or abusive purpose, including:
* money laundering, terrorist financing or sanctions evasion;
* transactions that breach applicable laws or regulations;
* impersonating a third party or misusing a payment method;
* using stolen or unauthorised payment credentials or accounts;
* unlawfully accessing or extracting personal, financial or protected data;
* attempting to damage or compromise Suby's infrastructure, including through card testing, bots or automated attacks;
* purchasing in breach of sanctions adopted by the European Union, the United Nations or France, including by or on behalf of a person subject to an asset freeze.
Suby does not sell to Customers located in North Korea, Iran, Crimea and Sevastopol, or the areas of the Donetsk, Kherson, Luhansk and Zaporizhzhia regions of Ukraine that are not controlled by the Government of Ukraine, or in any other territory where Suby or its payment partners do not offer their services. Such orders are declined before payment or, if a payment has been received, refunded, unless the law requires the funds to be withheld.
Where Suby has serious and objective grounds to suspect a breach of this Article, such as fraud signals, repeated declined payment attempts, a sanctions screening match or a payment method reported as stolen, it may decline or cancel the transaction and temporarily block further payment attempts from the same device, network or payment method. Unless the law prohibits it, Suby informs the Customer by a message at checkout or by email, and the Customer may ask for a review by a member of Suby's staff by writing to [contact@suby.fi](mailto:contact@suby.fi). Suby refunds any amount received for a Product not supplied, unless the law requires the funds to be withheld, and may report suspected illegal activity to the competent authorities.
## Article 14. Severability and non-waiver
If any provision of these T\&Cs is held invalid or unenforceable, it is deemed severed and, where possible, replaced by the applicable statutory provision. The other provisions remain in full force.
Suby's failure to enforce a provision at a given time does not mean that it waives the right to enforce it later.
## Article 15. Customer support and complaints
For any question, request or complaint about a purchase, the Customer can contact Suby:
* by email: [contact@suby.fi](mailto:contact@suby.fi)
* by telephone: +33 6 58 97 44 42
* by post: Suby SAS, Bureau 326, 59 rue de Ponthieu, 75008 Paris, France
Suby aims to resolve complaints within 30 days of receipt. If a complaint is not resolved to the Customer's satisfaction, the Customer may take the dispute to court under Article 17.
For technical help with a Product, the Customer may also use the Merchant's support channel shown at checkout. Suby remains the Customer's contact for any claim about the purchase.
## Article 16. Personal data
Suby processes the Customer's personal data as data controller in order to process orders and payments, have Products delivered by the Merchant, issue invoices and handle taxes, manage subscriptions, refunds, chargebacks and customer support, prevent fraud and comply with its legal obligations, including record-keeping and anti-money-laundering rules. The Merchant receives the data it needs to deliver the Product and provide support, and payment data is processed by Suby's payment partners.
Fraud prevention relies on automated checks at checkout, including a device fingerprint that can recognise the Customer's device across sessions (including in private browsing and after a VPN change), analysis of browsing signals such as mouse movements and typing rhythm to detect bots, a CAPTCHA where needed, and limits on repeated or declined payment attempts. These checks can automatically refuse a payment or temporarily block payment attempts linked to a device, network or account. The Customer may ask for any such decision to be reviewed by a member of Suby's staff, give their point of view and contest it by writing to [contact@suby.fi](mailto:contact@suby.fi).
The Customer has the rights of access, rectification, erasure, restriction, objection and portability, which can be exercised by writing to [contact@suby.fi](mailto:contact@suby.fi), and may lodge a complaint with the CNIL ([www.cnil.fr](http://www.cnil.fr)). Further details, including legal bases, retention periods and any transfers outside the European Union, are set out in Suby's [Privacy Policy](https://docs.suby.fi/v3-beta/docs/legal/privacy-policy).
## Article 17. Applicable law and jurisdiction
These T\&Cs are governed by French law. If the Customer is a consumer habitually resident in another country, this choice of law does not deprive them of the protection of the mandatory provisions of the law of that country (Article 6 of Regulation (EC) No 593/2008, "Rome I").
In the event of a dispute, the Customer may bring proceedings, at their choice, before any court with territorial jurisdiction under the French Code of Civil Procedure or before the court of the place where they lived when the contract was concluded or when the harmful event occurred (Article R631-3 of the French Consumer Code). A Customer domiciled in another EU Member State may also bring proceedings before the courts of that Member State (Article 18 of Regulation (EU) No 1215/2012).
## Annex 1. Model withdrawal form
*(Complete and return this form only if you wish to withdraw from the contract.)*
To: Suby SAS, Bureau 326, 59 rue de Ponthieu, 75008 Paris, France, [contact@suby.fi](mailto:contact@suby.fi)
I/We (\*) hereby give notice that I/We (\*) withdraw from my/our (\*) contract for the sale of the following goods (\*) / for the provision of the following service (\*):
* Ordered on (\*) / received on (\*):
* Transaction reference (as shown in the Order Confirmation):
* Name of consumer(s):
* Address of consumer(s):
* Signature of consumer(s) (only if this form is sent on paper):
* Date:
(\*) Delete as appropriate.
## Annex 2. Legal guarantee information
The following information is required by Articles D211-2 to D211-4 of the French Consumer Code. This is an English translation; the official text is the French version published on Légifrance.
**A. Physical goods**
> The consumer has two years from delivery of the goods to obtain the application of the legal guarantee of conformity if a lack of conformity appears. During this period, the consumer only needs to establish the existence of the lack of conformity, not the date on which it appeared.
>
> Where the contract for the sale of the goods provides for the continuous supply of digital content or a digital service for more than two years, the legal guarantee applies to that digital content or digital service throughout the planned supply period. During this period, the consumer only needs to establish the existence of the lack of conformity affecting the digital content or digital service, not the date on which it appeared.
>
> The legal guarantee of conformity requires the professional, where applicable, to provide all updates necessary to keep the goods in conformity.
>
> The legal guarantee of conformity entitles the consumer to have the goods repaired or replaced within thirty days of the request, free of charge and without major inconvenience.
>
> If the goods are repaired under the legal guarantee of conformity, the consumer benefits from a six-month extension of the initial guarantee.
>
> If the consumer requests repair but the seller imposes replacement, the legal guarantee of conformity is renewed for two years from the date of replacement.
>
> The consumer may obtain a reduction of the purchase price by keeping the goods, or terminate the contract and obtain a full refund against return of the goods, if:
>
> 1. the professional refuses to repair or replace the goods;
> 2. the repair or replacement takes place after thirty days;
> 3. the repair or replacement causes a major inconvenience for the consumer, in particular where the consumer permanently bears the cost of taking back or removing the non-conforming goods, or bears the cost of installing the repaired or replacement goods;
> 4. the lack of conformity persists despite the seller's unsuccessful attempt to bring the goods into conformity.
>
> The consumer is also entitled to a price reduction or to terminate the contract where the lack of conformity is so serious that it justifies an immediate price reduction or termination. The consumer is then not required to request repair or replacement first.
>
> The consumer is not entitled to terminate the sale if the lack of conformity is minor.
>
> Any period during which the goods are out of use for repair or replacement suspends the remaining guarantee period until the goods are returned in working order.
>
> These rights result from Articles L217-1 to L217-32 of the French Consumer Code.
>
> A seller who in bad faith obstructs the application of the legal guarantee of conformity is liable to a civil fine of up to €300,000, which may be increased to 10% of average annual turnover (Article L241-5 of the French Consumer Code).
>
> The consumer also benefits from the legal guarantee against hidden defects under Articles 1641 to 1649 of the French Civil Code, for two years from discovery of the defect. This guarantee entitles the consumer to a price reduction if the goods are kept, or to a full refund against return of the goods.
**B. Digital content or digital services supplied once or in a series of individual supplies**
> The consumer has two years from the supply of the digital content or digital service to obtain the application of the legal guarantee of conformity if a lack of conformity appears. For one year from the date of supply, the consumer only needs to establish the existence of the lack of conformity, not the date on which it appeared.
>
> The legal guarantee of conformity requires the supply of all updates necessary to keep the digital content or digital service in conformity.
>
> The legal guarantee of conformity entitles the consumer to have the digital content or digital service brought into conformity without undue delay after the request, free of charge and without major inconvenience.
>
> The consumer may obtain a price reduction by keeping the digital content or digital service, or terminate the contract and obtain a full refund by giving up the digital content or digital service, if:
>
> 1. the professional refuses to bring the digital content or digital service into conformity;
> 2. bringing the digital content or digital service into conformity is unjustifiably delayed;
> 3. the digital content or digital service cannot be brought into conformity without costs being imposed on the consumer;
> 4. bringing the digital content or digital service into conformity causes a major inconvenience for the consumer;
> 5. the lack of conformity persists despite the professional's unsuccessful attempt to bring the digital content or digital service into conformity.
>
> The consumer is also entitled to a price reduction or to terminate the contract where the lack of conformity is so serious that it justifies an immediate price reduction or termination. The consumer is then not required to request that the digital content or digital service be brought into conformity first.
>
> Where the lack of conformity is minor, the consumer is entitled to cancel the contract only if the contract does not provide for the payment of a price.
>
> Any period during which the digital content or digital service is unavailable while it is brought into conformity suspends the remaining guarantee period until conforming digital content or a conforming digital service is supplied again.
>
> These rights result from Articles L224-25-1 to L224-25-31 of the French Consumer Code.
>
> A professional who in bad faith obstructs the application of the legal guarantee of conformity is liable to a civil fine of up to €300,000, which may be increased to 10% of average annual turnover (Article L242-18-1 of the French Consumer Code).
>
> The consumer also benefits from the legal guarantee against hidden defects under Articles 1641 to 1649 of the French Civil Code, for two years from discovery of the defect. This guarantee entitles the consumer to a price reduction if the digital content or digital service is kept, or to a full refund in return for giving up the digital content or digital service.
**C. Digital content or digital services supplied continuously, such as subscriptions**
> The consumer is entitled to the application of the legal guarantee of conformity if a lack of conformity appears during the term of the subscription, including any renewals, from the supply of the digital content or digital service. During this period, the consumer only needs to establish the existence of the lack of conformity, not the date on which it appeared.
>
> The legal guarantee of conformity requires the supply of all updates necessary to keep the digital content or digital service in conformity during the term of the subscription, including any renewals.
>
> The legal guarantee of conformity entitles the consumer to have the digital content or digital service brought into conformity without undue delay after the request, free of charge and without major inconvenience.
>
> The consumer may obtain a price reduction by keeping the digital content or digital service, or terminate the contract and obtain a full refund by giving up the digital content or digital service, if:
>
> 1. the professional refuses to bring the digital content or digital service into conformity;
> 2. bringing the digital content or digital service into conformity is unjustifiably delayed;
> 3. the digital content or digital service cannot be brought into conformity without costs being imposed on the consumer;
> 4. bringing the digital content or digital service into conformity causes a major inconvenience for the consumer;
> 5. the lack of conformity persists despite the professional's unsuccessful attempt to bring the digital content or digital service into conformity.
>
> The consumer is also entitled to a price reduction or to terminate the contract where the lack of conformity is so serious that it justifies an immediate price reduction or termination. The consumer is then not required to request that the digital content or digital service be brought into conformity first.
>
> Where the lack of conformity is minor, the consumer is entitled to cancel the contract only if the contract does not provide for the payment of a price.
>
> Any period during which the digital content or digital service is unavailable while it is brought into conformity suspends the remaining guarantee period until conforming digital content or a conforming digital service is supplied again.
>
> These rights result from Articles L224-25-1 to L224-25-31 of the French Consumer Code.
>
> A professional who in bad faith obstructs the application of the legal guarantee of conformity is liable to a civil fine of up to €300,000, which may be increased to 10% of average annual turnover (Article L242-18-1 of the French Consumer Code).
>
> The consumer also benefits from the legal guarantee against hidden defects under Articles 1641 to 1649 of the French Civil Code, for two years from discovery of the defect. This guarantee entitles the consumer to a price reduction if the digital content or digital service is kept, or to a full refund in return for giving up the digital content or digital service.
## Annex 3. Statutory provisions on tacit renewal
Articles L215-1 to L215-3 and L241-3 of the French Consumer Code, reproduced as required by Article L215-4. This is an English translation; the official text is the French version published on Légifrance.
**Article L215-1**
> For service contracts concluded for a fixed term with a tacit renewal clause, the service provider shall inform the consumer in writing, by a dedicated personal letter or email, no earlier than three months and no later than one month before the end of the period during which renewal may be refused, that the consumer may choose not to renew the contract concluded with a tacit renewal clause. This information, given in clear and comprehensible terms, shall state the deadline for refusing renewal in a prominent box.
>
> Where this information has not been sent to the consumer in accordance with the first paragraph, the consumer may terminate the contract free of charge at any time from the renewal date.
>
> In that case, advance payments made after the last renewal date or, for contracts of indefinite duration, after the date on which the initial fixed-term contract was converted, shall be refunded within thirty days from the date of termination, less the amounts corresponding to the performance of the contract up to that date.
>
> This article applies without prejudice to the provisions that subject certain contracts to specific rules on consumer information.
>
> By way of exception to the first paragraph, for contracts for the supply of television services within the meaning of Article 2 of Law No. 86-1067 of 30 September 1986 on freedom of communication and for contracts for the supply of on-demand audiovisual media services, the consumer may terminate the contract free of charge at any time from the first renewal if they move home or their tax household changes.
**Article L215-1-1**
> Where a contract was concluded electronically, or was concluded by other means and the professional, on the day the consumer terminates it, offers consumers the possibility of concluding contracts electronically, termination shall be possible by electronic means.
>
> To this end, the professional shall provide the consumer with a free function allowing the notification and steps necessary to terminate the contract to be completed electronically. When the consumer gives notice of termination, the professional shall confirm receipt of the notice and inform the consumer, on a durable medium and within a reasonable time, of the date on which the contract ends and the effects of termination.
>
> A decree shall set out, in particular, the technical arrangements ensuring the identification of the consumer and easy, direct and permanent access to the function mentioned in the second paragraph, such as how it is presented and used. It shall determine the information to be provided by the consumer.
**Article L215-2**
> The provisions of this chapter, except Article L215-1-1, do not apply to operators of drinking water and sanitation services.
**Article L215-3**
> The provisions of this chapter also apply to contracts concluded between professionals and non-professionals.
**Article L241-3**
> Where the professional has not made the refund under the conditions provided for in Article L215-1, the sums due shall bear interest at the legal rate.
# Review Process
Source: https://docs.suby.fi/v3-beta/docs/merchants/account-review-process
How we evaluate your business before onboarding you on Suby.
Suby reviews every application directly. We keep a direct relationship with our merchants and walk you through the process from start to finish, so you always know where your application stands.
## How it works
You start by telling us whether you're applying as a **Company** or as an **Individual**. This determines whether you'll go through KYB & KYC or KYC only verification later in the process.
We ask you to describe your business in detail: business type, a clear description of what you sell, your merchant category code (MCC), expected transaction volume, and your social/web presence (website, socials, or any public profile of your activity).
Be as detailed as possible. This is the information we use to understand your business, and applications with little or vague information will be rejected. A thin or generic answer here is the most common reason applications don't move forward.
Depending on whether you applied as a Company or an Individual, you'll be asked to submit the relevant documents:
* **Individuals** complete a KYC (Know Your Customer) check, submitting proof of identity and address.
* **Companies** complete a KYC and a KYB (Know Your Business) check, submitting business registration documents, proof of ownership structure, and identification for authorized representatives.
Final approval is also subject to review by our licensed PSP partners. This step usually runs in parallel with our own review.
Our team reviews your full file, business information plus KYC/KYB documents, and decides whether to approve your application.
If approved, we assign your account to **MoR** or **PayFac** mode based on your business type, sales volume, target markets, and risk profile. We'll walk you through what this means for you and why, see [MoR vs PayFac](#mor-or-payfac) below.
Once approved and your mode is assigned, your account is activated. You can create products, generate PayLinks, and start accepting payments immediately.
## What happens after you apply
Once your business information and KYC/KYB documents are reviewed and approved, we assign your account's mode (MoR or PayFac) and activate your Suby account.
If your business description, MCC, volume, or socials aren't detailed enough for us to understand your business, or if a KYC/KYB document is missing or unclear, our team will reach out directly to request what's needed. Once we have it, your application is reviewed again.
If your business was rejected, it means it falls outside our current eligibility criteria, either due to the nature of the business, the country of operation, insufficient information provided, or our PSP partner requirements.
You're welcome to reach out to our support team if you believe there's been an error, if your situation has changed, or if you'd like to resubmit with more complete information.
Reach out via the support page or at [contact@suby.fi](mailto:contact@suby.fi)
## MoR or PayFac
Suby assigns your account to Merchant of Record or PayFac mode, it isn't something you self-select when applying. Once your file is approved, our team looks at your business type, sales volume, target markets, and risk profile to determine which model fits best, and we'll explain it to you directly before you go live.
Suby is the legal seller of record and handles tax compliance for you. Typically the better fit if you're selling into many jurisdictions and want to avoid managing global tax registration yourself.
You remain the seller of record and handle your own tax compliance. Typically a better fit if you already have your own tax setup, or want the lower per-transaction fee.
## Will my business be accepted?
The best way to know upfront is to check the list of supported and prohibited business types before applying. These criteria apply regardless of which mode you're eventually assigned to.
See which business categories are accepted on Suby.
Check if your country is covered for seller accounts.
Meeting the criteria on those pages is a strong signal, but final approval also depends on the completeness of your application and our PSP partners' requirements, which may vary. When in doubt, apply with as much detail as possible and we'll let you know.
# Understand Your Fees
Source: https://docs.suby.fi/v3-beta/docs/merchants/fees-mor
Transparent, predictable pricing on every transaction, MoR mode.
This page covers pricing for **MoR mode**. If you're on **PayFac mode**, see [Fees (PayFac)](/v3-beta/docs/merchants/fees-payfac) instead.
Suby charges a single flat fee per transaction. No setup fees, no monthly costs, no hidden charges.
## Card Payments
**4% + \$0.40** per transaction
Card fees are deducted at payout time, not at transaction time. Your payout reflects the net amount after fees. This fee covers payment processing, tax calculation, collection and remittance, and chargeback/dispute protection, see [What is a Merchant of Record?](/v3-beta/docs/merchants/what-is-a-merchant-of-record) for what's included.
## Crypto Payments
Crypto payments are charged **1.5% per transaction**, applied on-chain via smart contract at execution time.
| Fee | Amount |
| - | - |
| Transaction fee | 1.5% per transaction |
| Payout fee | See below |
There are no fixed fees on crypto payments. You receive the net amount directly in your wallet or Suby Balance the moment the transaction confirms.
## Payouts
Payout fees are the same regardless of mode.
| Payout method | Fee |
| - | - |
| Bank account (USD/EUR) | \$0.50 per payout |
| Crypto wallet (USDC/EURC) | 0.5% + \$1 per payout |
## Why MoR Costs More Than PayFac
The 4% + \$0.40 fee covers more than payment processing: Suby calculates, collects, and remits your sales tax and VAT worldwide, and absorbs part of the risk on chargeback and dispute ratios. If you'd rather handle tax and dispute management yourself at a lower per-transaction cost, that's what PayFac mode offers, see [Fees (PayFac)](/v3-beta/docs/merchants/fees-payfac).
## Fee Visibility
All fees are fully visible in your dashboard, per-transaction breakdowns, net amounts received, and payout-level summaries. Nothing is hidden.
# Understand Your Fees
Source: https://docs.suby.fi/v3-beta/docs/merchants/fees-payfac
Transparent, predictable pricing on every transaction, PayFac mode.
This page covers pricing for **PayFac mode**. If you're on **MoR mode**, see [Fees (MoR)](/v3-beta/docs/merchants/fees-mor) instead.
Suby charges a single flat fee per transaction. No setup fees, no monthly costs, no hidden charges.
## Card Payments
**2.9% + \$0.30** per transaction
Card fees are deducted at payout time, not at transaction time. Your payout reflects the net amount after fees. This fee covers payment processing only, tax handling and dispute management are your own responsibility in this mode, see [What is PayFac?](/v3-beta/docs/merchants/what-is-a-payfac).
## Crypto Payments
Crypto payments are charged **1.5% per transaction**, applied on-chain via smart contract at execution time.
| Fee | Amount |
| - | - |
| Transaction fee | 1.5% per transaction |
| Payout fee | See below |
There are no fixed fees on crypto payments. You receive the net amount directly in your wallet or Suby Balance the moment the transaction confirms.
## Payouts
Payout fees are the same regardless of mode.
| Payout method | Fee |
| - | - |
| Bank account (USD/EUR) | \$0.50 per payout |
| Crypto wallet (USDC/EURC) | 0.5% + \$1 per payout |
## Why PayFac Costs Less Than MoR
The 2.9% + \$0.30 fee covers payment processing only. Unlike MoR mode, Suby does not calculate, collect, or remit tax on your behalf, and does not absorb dispute or chargeback risk for you, you manage both yourself. If you'd rather have tax and dispute management handled for you at a higher per-transaction cost, that's what MoR mode offers, see [Fees (MoR)](/v3-beta/docs/merchants/fees-mor).
## Fee Visibility
All fees are fully visible in your dashboard, per-transaction breakdowns, net amounts received, and payout-level summaries. Nothing is hidden.
# Supported Businesses
Source: https://docs.suby.fi/v3-beta/docs/merchants/supported-businesses
Which business types Suby supports and which are not permitted on the platform.
Suby is built for digital-first businesses. Before applying, make sure your business falls within the supported categories below.
This policy exists to protect merchants, customers, and the integrity of Suby's payment infrastructure. Accounts that violate this policy may be suspended or restricted without notice.
## Supported Businesses
Web apps and SaaS products, AI tools and APIs, developer tools, trading and analytics tools, bots and automation tools.
Templates and design assets, eBooks and PDFs, code and scripts, courses and educational content, digital downloads.
Paid Discord servers and roles, Telegram groups and channels, subscription-based newsletters, private content libraries, creator memberships.
Physical goods sold online, print-on-demand products, dropshipping stores, branded merchandise, online retail shops.
Coaching and consulting, premium research and analytics, agency retainers, freelance service packages.
Suby supports businesses with fully digital fulfillment or standard physical goods e-commerce, a transparent value proposition, no deceptive marketing or fake social proof, and reasonable chargeback and refund risk. If you are unsure whether your business qualifies, [contact the team](https://www.suby.fi/support) before integrating.
## Prohibited Businesses
The following categories are not permitted on Suby. This list is not exhaustive, we reserve the right to restrict any account that presents significant compliance, regulatory, fraud, or chargeback risk.
Illegal goods or services of any kind, drugs and controlled substances, age-restricted goods (alcohol, tobacco, vaping products, puffs, nicotine pouches), counterfeit goods, copyright or trademark violations, selling products without the required IP rights or licenses, weapons, ammunition, weapon parts and lethal tactical gear, live animals and products derived from protected species (CITES, ivory, exotic wildlife), kratom, kava, poppers, research chemicals, and unapproved nootropics.
Gambling, lootboxes, mystery boxes, and random pack openings, sweepstakes, lotteries, and get-rich-quick schemes, unlicensed financial services, securities offerings, investment funds and high-yield investment programs, unregulated trading pools, forex, trading signals, copy-trading, and prop firms, cryptocurrencies, NFTs, tokens, ICOs, and mining-as-a-service, crowdfunding, donation collection, and cash-advance services, gift cards, prepaid cards, e-money, mobile top-ups, and money transfer services, regulated services (real estate, mortgage, lending, legal, banking, debt relief, warranties), telecommunication, IPTV, and eSIM services.
Fake testimonials or manufactured social proof, review manipulation platforms, sale of followers, likes, views, comments, or any artificial engagement, selling customer data, scraped data, email lists, and lead databases, cloaking services (IP or API cloaking to bypass bans or rate limits), services designed to circumvent third-party platform restrictions, fake or fraudulent document generators (invoices, payslips, IDs, diplomas, proof of address), homework or essay mills, MLM, pyramid schemes, and IBO schemes, high-ticket coaching or mentoring promising guaranteed income or results.
Virus, spyware, malware, and parental control apps marketed for covert surveillance, face-swap, deepfake, and face-manipulation tools or services, sexually-oriented or pornographic content of any kind, dating sites and adult companionship services, medical or pharmaceutical advice, pharmacies, pharmaceuticals, and nutraceuticals, weight-loss or muscle-building pharmaceutical products, steroids, SARMs, peptides, and hormones, contact lenses, medical devices, and direct-to-consumer diagnostic tests, occult or esoteric services (psychic readings, spell casting, curse removal, love spells), extremist, hateful, or violence-inciting content, services targeted at minors.
Stresser, booter, and DDoS-for-hire services, game cheats, hacks, bots, boosted accounts, and unauthorized in-game currency, sale or rental of social media, streaming, or online accounts, DRM circumvention, SIM unlocking, and jailbreak-as-a-service, VPNs or proxies marketed to bypass sanctions or commit fraud, SMS pumping, OTP bypass, and traffic-inflation services, OSINT or surveillance tools sold for tracking individuals without consent.
Marketplaces where Suby is used to resell other people's products, dropshipping with delivery times exceeding 30 days, ticket resale and timeshare offers, pre-orders or crowdfunded products that are not yet manufactured or in stock, products for which you do not hold proper IP rights.
Auto-renewing subscriptions without clear and explicit consent (negative option billing), hidden fees or undisclosed recurring charges, misleading free trials that convert without notice, refusal to honor refund or cancellation requests within stated terms.
Suby may restrict businesses with chargeback rates exceeding 1%, significant compliance or regulatory risk, or that threaten the reputation of Suby or our payment infrastructure partners.
## Compliance Requirements
Suby works with global payment infrastructure partners across both its modes. What you're required to comply with depends on which mode your account runs on:
* **MoR mode**: Suby itself acts as Merchant of Record for your transactions. Your business must comply with card network rules (Visa and Mastercard policies) and crypto compliance standards; Suby handles international tax compliance on your behalf, as described in Taxes & VAT Handling.
* **PayFac mode**: you remain the seller of record. In addition to card network and crypto compliance standards, your business must independently comply with international tax regulations applicable to your jurisdiction and every jurisdiction you sell into.
You remain responsible for your own income and corporate tax obligations regardless of mode.
Reach out before integrating if you are unsure whether your use case is supported.
# Supported Countries
Source: https://docs.suby.fi/v3-beta/docs/merchants/supported-countries
Suby's checkout is available globally, with restrictions in sanctioned regions.
Suby's checkout is available worldwide for both card and stablecoin payments, sellers and customers from virtually every country can use the platform.
## Sellers
Suby onboards merchants from every country in the world. If you can run an internet business, you can use Suby, regardless of where you are based.
If you run into any issue during onboarding related to your country, [contact the team](https://www.suby.fi/support).
## Customers
Your customers can pay from anywhere in the world. There are no geographic restrictions on where your buyers are located, with the exception of sanctioned regions listed below.
## Restricted Regions
To comply with international sanctions and regulations, Suby does not support payments from the following jurisdictions:
* North Korea
* Iran
* Syria
* Cuba
* Crimea, Donetsk, and Luhansk regions
* Any other jurisdiction subject to applicable international sanctions
Restrictions apply to both card and stablecoin payments. This list may change based on regulatory updates.
## Important Notes
Merchants are responsible for ensuring their business complies with applicable local laws in the countries they sell into. Suby does not guarantee availability in all regions at all times.
Reach us on WhatsApp, Telegram, Discord, or email if you have questions about your region.
# Supported Currencies
Source: https://docs.suby.fi/v3-beta/docs/merchants/supported-currencies
What customers can pay with at checkout, and how pricing and conversions work.
Suby supports fiat and stablecoin payments at checkout. Customers choose their preferred method and Suby handles the rest.
Suby operates in two modes, **All Payment Methods** and **Crypto Only**, which determine how your funds are held and settled after a payment. See below for details on each.
## Classic Payment Methods
### Accepted Methods
Visa, Mastercard, Amex, and all major networks.
Available on supported Apple devices and browsers.
Available on supported Android devices and browsers.
Pay now, pay later, or in installments where available.
Direct bank transfer.
### Pricing Currency
All fiat payments are currently priced in **USD & EUR**.
If a customer's card or bank account is denominated in another currency, their bank handles the FX conversion at the time of payment. Suby does not apply any additional conversion fee.
### Settlement
Fiat payment proceeds are settled through Suby's payment infrastructure and appear in your dashboard, and in your **Suby Balance**, in USD or EUR. Once settled, the funds are available for withdrawal, you decide when to withdraw them to your configured bank account or crypto wallet, there's no fixed automatic payout schedule.
## Stablecoin & Crypto Payments
### Supported Tokens & Networks
| Network | Tokens |
| - | - |
| Ethereum | USDC, USDT, ETH |
| Arbitrum | USDC, ETH |
| Base | USDC, ETH |
| Solana | USDC, SOL |
| BNB Chain | USDC, USDT, BNB |
| Monad | USDC, USDT0, MON |
| BTC | BTC |
| Polygon | USDC, USDT0, POL |
### Pricing & Conversion
Crypto payments are priced in USD or EUR. When a customer selects a token at checkout, Suby converts the USD or EUR price into the exact token amount using **Pyth price feeds** at the time of the transaction.
A high-frequency oracle network providing real-time price feeds for all supported assets. The rate is locked at checkout for the duration of the session.
The customer sees the USD price and the exact token amount before confirming. Your dashboard records both the USD equivalent and the token paid.
### Settlement
Settlement depends on your mode:
* **All Payment Methods mode**: crypto payments are auto-converted to USDC on Base and credited instantly to your **Suby Balance**, alongside your fiat payments. You withdraw from your balance to your bank account or wallet whenever you choose.
* **Crypto Only mode**: payments are non-custodial and do not pass through your Suby Balance. Funds are sent directly to your configured wallet, either as the exact asset and network the customer paid with, or auto-converted to USDC on Base, depending on your settings. No intermediary holds your assets.
## FAQ
USD & EUR are the only supported pricing currency for now. If you need to sell in a specific currency, [contact the team](https://www.suby.fi/support).
The token amount is calculated and locked when the customer initiates the checkout session. If the session expires before payment is confirmed, a new rate is applied.
Crypto payments are charged at a flat **1.5% transaction fee**, lower than card payments. Network gas fees are paid by the customer at the time of the on-chain transaction.
It depends on your mode. In **All Payment Methods mode**, all payments, including crypto, are converted to USDC on Base in your Suby Balance, so you always withdraw in USDC or EURC, not the original token. In **Crypto Only** mode, you choose: receive the exact asset and network the customer paid with, no conversion, or auto-convert everything to USDC on Base.
# Taxes & VAT Handling
Source: https://docs.suby.fi/v3-beta/docs/merchants/taxes-vat-mor
How Suby calculates, collects, and remits taxes automatically on every transaction.
This page covers the technical details of how tax handling works in **MoR mode**. If you're on **PayFac mode**, see [Taxes & VAT Handling (PayFac)](/v3-beta/docs/merchants/taxes-vat-payfac) instead, tax handling is entirely your own responsibility there.
## How It Works at Checkout
Suby detects the customer's location from their billing address, cross-referenced with IP geolocation.
The applicable tax type and rate for that jurisdiction are identified in real time.
The tax is applied to the transaction automatically, tax-inclusive or tax-exclusive depending on the jurisdiction.
Tax is collected as part of the payment at checkout.
Suby, as Merchant of Record, files and remits the tax to the relevant authority on your behalf.
![Newcheckout]()
## Coverage
| Tax type | Jurisdictions |
| - | - |
| VAT (Value Added Tax) | European Union, United Kingdom, and other VAT jurisdictions |
| GST (Goods and Services Tax) | Australia, Canada, India, New Zealand, and others |
| Sales tax | United States, state and local level |
| Digital services taxes | All applicable jurisdictions globally |
## B2B Transactions
For business customers in VAT jurisdictions, Suby supports reverse charge mechanisms where applicable. When a customer provides a valid VAT ID at checkout, the transaction is treated as a B2B sale and the reverse charge is applied automatically.
The answer is kept on the customer, so later charges taken without them on the page — a subscription renewal, an off-session debit for usage — are priced the same way, rather than falling back to consumer VAT. You can see and change it on the customer in your dashboard.
## What You Remain Responsible For
Tax coverage through Suby applies to sales taxes on transactions, VAT, GST, and equivalent taxes. It does not cover your own income tax or corporate tax obligations in your jurisdiction.
You remain responsible for declaring and paying your own income and corporate tax. If you have specific questions about how taxes apply to your business, consult a tax advisor or [contact the Suby team](https://www.suby.fi/support).
## FAQ
Yes. In jurisdictions where tax-inclusive pricing is standard (such as most of the EU), the price shown already includes tax. In others (such as the US), tax is shown as a separate line item.
Suby uses a combination of billing address and IP geolocation to determine the customer's location. If the two signals conflict, additional checks are applied. Fraudulent location misrepresentation is the customer's liability, not yours.
Yes. Your dashboard shows a breakdown of taxes collected per transaction and per period, which you can export for your own accounting records.
Yes. Suby calculates and remits US sales tax at the state and local level based on the customer's location, including economic nexus rules. You do not need to track nexus thresholds yourself.
Mode assignment is handled by Suby based on your business profile, not self-selected. If you think PayFac would be a better fit for you, [contact the team](https://www.suby.fi/support) to discuss it.
# Taxes & VAT Handling
Source: https://docs.suby.fi/v3-beta/docs/merchants/taxes-vat-payfac
In PayFac mode, tax calculation, collection, and remittance are entirely your own responsibility.
This page covers tax handling in **PayFac mode**. If you're on **MoR mode**, see [Taxes & VAT Handling (MoR)](/v3-beta/docs/merchants/taxes-vat-mor) instead, tax is handled automatically for you there.
In PayFac mode, Suby is not the Merchant of Record, you are the seller of record for every sale. Suby does not calculate, collect, apply, or remit any sales tax, VAT, or GST on your behalf. This is a significant difference from MoR mode, read this page carefully before going live.
## What Suby Does Not Do in PayFac Mode
Suby does not detect the applicable tax type or rate, or apply it at checkout.
Suby does not collect any tax amount from your customers on your behalf.
Suby does not file or remit any sales tax, VAT, or GST to any authority for your sales.
Suby does not track US economic nexus thresholds or any equivalent registration threshold elsewhere.
## What You're Responsible For
You must register for VAT, GST, or sales tax in every jurisdiction where you become liable to, based on your own sales volumes and local thresholds (for example, economic nexus rules in the US, or VAT OSS registration in the EU).
For each sale, you determine the applicable tax type and rate based on your customer's location and your own tax registrations.
You are responsible for including and collecting the correct tax amount as part of the price your customer pays.
You file returns and remit collected tax to the relevant authorities, on your own schedule, in every jurisdiction where you're registered.
You remain responsible for declaring and paying your own income and corporate tax as well, in both PayFac and MoR mode. This page only covers sales tax, VAT, and GST on transactions.
## What Suby Does Provide
Suby's dashboard shows you the gross amount, fees, and net proceeds per transaction, which you can export for your own accounting and tax filing. Suby does not calculate or itemize tax within these records, since it does not handle tax in this mode.
If you're unsure whether you can handle global tax compliance yourself, MoR mode may be a better fit, it removes this responsibility entirely. [Contact the team](https://www.suby.fi/support) to discuss switching.
## FAQ
That depends entirely on how you configure your own checkout and pricing. Suby does not calculate, display, or itemize tax for you in PayFac mode, you need to build this into your pricing yourself.
No. Nexus tracking, registration, and remittance are entirely your responsibility in PayFac mode. See [What is a Merchant of Record?](/v3-beta/docs/merchants/what-is-a-merchant-of-record) if you'd prefer this handled for you.
Suby does not provide tax advice. We recommend consulting a qualified tax advisor familiar with the jurisdictions you sell into. See the Education section for general guidance.
Mode assignment is handled by Suby based on your business profile, not self-selected. If you think MoR would be a better fit for you, [contact the team](https://www.suby.fi/support) to discuss it.
# What is a Merchant of Record?
Source: https://docs.suby.fi/v3-beta/docs/merchants/what-is-a-merchant-of-record
How Suby handles tax compliance, liability, and global payment infrastructure on your behalf.
When you sell globally, someone has to be legally responsible for the transaction, collecting taxes, remitting them to the right authorities, and absorbing the compliance liability. That entity is called the Merchant of Record.
This page describes **MoR mode**. Suby also offers a **PayFac mode**, where you remain the seller of record and handle your own tax compliance, see What is PayFac?. Which mode your account runs on is assigned by Suby during onboarding, see Review Process.
## What a Merchant of Record Does
A Merchant of Record (MoR) is the legal entity that sells the product to the customer, calculates, collects, and remits international sales taxes (VAT, GST, US Sales Tax), assumes regulatory and tax liability for the transaction, and handles chargebacks and fraud liability.
Without a MoR, you are responsible for all of this yourself, registering for tax in every jurisdiction you sell into, filing returns, and absorbing compliance risk. This is the case on Suby's PayFac mode.
## PSP vs MoR vs Suby
| | PSP (e.g. Stripe) | MoR (e.g. Paddle) | Suby (MoR mode) |
| - | - | - | - |
| Processes payments | ✅ | ✅ | ✅ |
| Tax collection and remittance | ❌ | ✅ | ✅ |
| Compliance liability | ❌ | ✅ | ✅ |
| Stablecoin-native payouts | ❌ | ❌ | ✅ |
| Discord and Telegram integrations | ❌ | ❌ | ✅ |
| You control billing infrastructure | ✅ | Partial | ✅ |
Low-level APIs and maximum flexibility, but you remain liable for international tax compliance. You must register, file, and remit taxes yourself. This is comparable to Suby's PayFac mode.
Handle compliance but often come with higher fees, less flexibility, and limited payment method support.
Suby itself acts as the licensed Merchant of Record for your transactions. Automated tax handling and compliance coverage without giving up control over your billing infrastructure or payment methods.
## How Suby Handles Compliance
In MoR mode, Suby itself is the Merchant of Record: the legal seller of your Products to your customers. We handle card payments, stablecoin payments, Discord and Telegram integrations, and recurring billing on top of that role.
Suby handles tax registration, collection, and remittance across 190+ countries, as the entity legally responsible for the sale.
You are not liable for international tax registrations or filings on these sales.
Suby absorbs the compliance layer so you never interact with it directly.
You remain responsible for your own income and corporate tax in your jurisdiction.
## What This Means for You
Every transaction is tax-compliant automatically. You never register for foreign VAT or GST, and you never file tax returns in markets where you sell.
Customers see the correct tax-inclusive or tax-exclusive price at checkout based on their location.
Chargebacks and fraud liability are handled at the infrastructure level, within the limits described in your terms.
You focus on building and selling. We handle the legal and compliance layer underneath.
***
The technical detail of how tax is calculated, collected, and remitted in MoR mode.
Pricing for MoR mode: 4% + \$0.40 per transaction.
Where Suby's checkout is available and which regions are restricted.
Which business types are supported and which are not.
# What is PayFac?
Source: https://docs.suby.fi/v3-beta/docs/merchants/what-is-a-payfac
How Suby's PayFac mode works: you stay the seller of record, Suby processes the payment.
A Payment Facilitator (PayFac) is a model where Suby enables you to accept card and crypto payments through its infrastructure, but you remain the legal seller of the product. Unlike MoR mode, Suby is not a party to the sale, you carry the tax and compliance responsibility yourself.
This page describes **PayFac mode**. Suby also offers a **MoR mode**, where Suby itself is the seller of record and handles tax compliance for you, see [What is a Merchant of Record?](/v3-beta/docs/merchants/what-is-a-merchant-of-record). Which mode your account runs on is assigned by Suby during onboarding, see [Review Process](/v3-beta/docs/merchants/account-review-process).
## What PayFac Means for You
In PayFac mode, you are the seller of record for every transaction. Suby's role is limited to enabling and processing the payment:
* You sell the product to the customer, in your own name;
* You calculate, collect, declare, and remit any applicable sales tax, VAT, or GST yourself, worldwide;
* You are responsible for your own dispute and chargeback ratios;
* Suby processes the payment, settles funds to your Suby Balance or wallet, and provides the technical infrastructure (checkout, API, dashboard).
Without a Merchant of Record handling this for you, you carry the same tax registration, filing, and compliance responsibilities you'd have running your own payment stack directly with a PSP.
## PayFac vs MoR vs Suby MoR mode
| | PSP (e.g. Stripe) | MoR (e.g. Paddle) | Suby (PayFac mode) |
| - | - | - | - |
| Processes payments | ✅ | ✅ | ✅ |
| Tax collection and remittance | ❌ | ✅ | ❌ (you handle it) |
| Compliance liability | ❌ | ✅ | ❌ (you carry it) |
| Stablecoin-native payments | ❌ | ❌ | ✅ |
| Discord and Telegram integrations | ❌ | ❌ | ✅ |
| You control billing infrastructure | ✅ | Partial | ✅ |
| Lower per-transaction fee | ✅ | ❌ | ✅ |
Suby processes your payments through its infrastructure, card, Apple Pay, Google Pay, Klarna, stablecoins, at a lower fee than MoR mode, in exchange for you keeping tax and dispute-management responsibility.
## How Suby Handles Payments in PayFac Mode
Suby processes the transaction on your behalf as payment facilitator. It is not a party to the sale contract between you and your customer.
Suby does not calculate, collect, or remit any tax on your sales. See [Taxes & VAT Handling (PayFac)](/v3-beta/docs/merchants/taxes-vat-payfac) for what you need to set up yourself.
You are responsible for your own chargeback and refund ratios. Accounts exceeding acceptable thresholds may be restricted, see [Supported Businesses](/v3-beta/docs/merchants/supported-businesses).
## What This Means for You
2.9% + \$0.30 per transaction, lower than MoR mode, since Suby's scope is limited to payment processing.
You keep control over invoicing and customer relationship as seller of record, but you also carry tax registration and compliance risk.
Cards, Apple Pay, Google Pay, Klarna, bank transfers, and crypto, all available exactly as in MoR mode.
Dispute and chargeback ratios are your responsibility. See the Education section for guidance.
***
What you need to set up yourself for global tax compliance.
Pricing for PayFac mode: 2.9% + \$0.30 per transaction.
Where Suby's checkout is available and which regions are restricted.
Which business types are supported and which are not.
# Understand Your Fees
Source: https://docs.suby.fi/v3-beta/docs/payment/fees
Transparent, predictable pricing on every transaction, card and crypto.
Suby charges a single flat fee per transaction. No setup fees, no monthly costs, no hidden charges.
## Card Payments
Suby operates in two modes, Merchant of Record and PayFac. Your transaction fee depends on which mode your account runs on.
**4% + \$0.40** per tx
**2.9% + \$0.30** per tx
Card fees are deducted at payout time, not at transaction time. Your payout reflects the net amount after fees. See the [full pricing page](https://www.suby.fi/pricing) for a detailed breakdown of what's included in each mode.
## Crypto Payments
Crypto payments are charged **1.5% per transaction**, applied on-chain via smart contract at execution time.
| Fee | Amount |
| - | - |
| Transaction fee | 1.5% per transaction |
| Payout fee | See below, same rates in both modes |
There are no fixed fees on crypto payments. You receive the net amount directly in your wallet the moment the transaction confirms.
## Payouts
Payout fees are the same regardless of whether you're on Merchant of Record or PayFac mode.
| Payout method | Fee |
| - | - |
| Bank account (USD/EUR) | \$0.50 per payout |
| Crypto wallet (USDC/EURC) | 0.5% + \$1 per payout |
## Why Fees Differ Between MoR and PayFac
The 4% + \$0.40 vs 2.9% + \$0.30 gap reflects what Suby handles on your behalf in each mode, not just payment processing.
**Merchant of Record (4% + \$0.40)**: Suby acts as the seller of record for your transactions. That fee covers:
* Calculating, collecting, and remitting sales tax / VAT on your behalf, worldwide;
* Protection against high dispute and chargeback ratios, Suby absorbs part of that risk and manages the underlying card scheme relationships for you.
**PayFac (2.9% + \$0.30)**: you remain the seller of record. That lower fee reflects a narrower scope: Suby only handles payment processing. As a result:
* You are responsible for calculating, collecting, and remitting sales tax / VAT worldwide yourself;
* You are responsible for managing and staying within acceptable dispute and chargeback ratios yourself.
See the [Education](/v3-beta/docs/education/disputes-chargeback) section for guidance on managing chargeback ratios if you're on PayFac.
Card payments also involve traditional payment networks, issuing banks, and dispute handling, each introducing fixed and variable costs on top of the above. Crypto payments settle directly on-chain with no intermediaries, which is why the fee structure is simpler and lower overall.
## Fee Visibility
All fees are fully visible in your dashboard, per-transaction breakdowns, net amounts received, and payout-level summaries. Nothing is hidden.
# Pay-ins & Payouts
Source: https://docs.suby.fi/v3-beta/docs/payment/payins-payouts
Supported payment methods and payout options on Suby.
## Two modes
Suby supports two account modes. Which one you're on determines which payment methods are available, whether KYC/KYB is required, and how your funds are held before withdrawal.
![Two Modes]()
Accept cards, wallets, Klarna, and crypto. Requires KYC/KYB. All payments, whatever the method, are converted and credited to your **Suby Balance** in USD or EUR.
Accept crypto payments only. No KYC/KYB required. Choose to receive assets exactly as paid (no conversion), or auto-converted to USDC on Base.
***
## Pay-ins: All Payment Methods Mode
Customers can pay using any of the following methods at checkout.
Visa, Mastercard, American Express
Available on supported devices and browsers
Available on supported devices and browsers
Pay now, pay later, or in installments where available
Direct bank transfer
Any supported network and asset, see below
In All Payment Methods mode, whatever the customer pays with, funds are converted and credited to your Suby Balance in USD & EUR.
### Supported crypto networks & assets (All Payment Methods mode pay-in)
| Network | Assets accepted |
| - | - |
| Base | ETH, USDC |
| Solana | SOL, USDC, USDT |
| Ethereum | ETH, USDC, USDT |
| Bitcoin | BTC |
| Arbitrum | ETH, USDC |
| Polygon | USDC, USDT0, POL |
| Monad | MON, USDC, USDT0 |
| BSC | BNB, USDC, USDT |
All of the above are automatically converted to USDC on Base and credited to your Suby Balance.
***
## Pay-ins: Crypto Only mode
No KYC/KYB required. You choose, per your account settings, how incoming crypto payments are handled:
No conversion. You receive the exact asset and network the customer paid with directly to your wallet.
Whatever the customer pays with, you receive USDC on Base.
**Example: Receive as paid:** a customer pays in ETH on Base → you receive ETH on Base.
**Example: Auto-convert:** a customer pays in SOL on Solana → you receive USDC on Base.
![Auto Convert Vs Keep Asset]()
Crypto Only payments are non-custodial and do not pass through your Suby Balance. Suby never holds your funds, they are sent directly to your configured wallet.
***
## How payouts work: All Payment Methods mode
In All Payment Methods mode, every payment you receive is first credited to your **Suby Balance**. From there, you decide when and where to withdraw it, either to a bank account or to a crypto wallet, in **Settings → Payouts Settings**.
Suby Balance is not a bank account or a custodial wallet, it is simply a running total of what you're owed, held with our custody partner until you request a withdrawal.
\$0.50 per withdrawal, USD/EUR
1% for local currency payouts
0.5% + \$1 per withdrawal
Crypto Only mode does not use the Suby Balance or the withdrawal flow described below, funds are sent directly to your wallet at the time of payment, as described above.
***
## Bank Withdrawal Flow
The customer completes payment at checkout, by card, bank transfer, Klarna, or crypto.
Funds are cleared through Suby's payment partners, card networks, issuing banks, acquiring banks, or on-chain settlement, and credited to your Suby Balance.
Once you request a withdrawal, funds are sent to your bank account in USD, EUR, or your local currency, depending on your settings.
Bank withdrawals take **3 to 5 business days** after your request. A minimum balance of **\$10** is required to trigger a withdrawal. Need it faster? [Contact the team](https://www.suby.fi/support).
***
## Wallet Withdrawal Flow
The customer completes payment at checkout, by card, bank transfer, Klarna, or crypto.
Once cleared, the amount is credited to your Suby Balance.
Once you request a withdrawal, funds are sent to your configured non-custodial wallet as USDC or EURC on your selected network.
![Wallet Withdraw]()
Withdrawals to your wallet are irreversible, double-check your wallet address before confirming.
| Network | Assets you can receive |
| - | - |
| Base | USDC, EURC |
| Polygon (Soon) | USDC |
| Solana (Soon) | USDC |
Your payout method and network are configured in **Settings → Payouts Settings**.
***
## Payout History
Track all withdrawals in **Revenue → Balance**. For each withdrawal you can see:
* Status
* Amount
* Description
* Date
![Payout History]()
***
## Setting Up Payouts
Navigate to **Settings → Payouts Settings** in your dashboard.
Select your preferred withdrawal method: bank account or crypto wallet.
Fill in your bank account information or your crypto wallet address, depending on the method you chose.
Your Suby Balance will be available to withdraw to this destination whenever you choose.
![Payout Settings]()
***
## FAQ
Full mode supports cards, wallets, Klarna, and crypto, requires KYC/KYB, and routes all funds through your Suby Balance before you withdraw. Crypto Only accepts crypto payments exclusively, requires no KYC/KYB, and sends funds directly to your wallet at the time of payment, either as paid or auto-converted to USDC on Base, your choice.
A minimum Suby Balance of \$10 is required to trigger a bank withdrawal. Balances below this threshold carry over until your next withdrawal.
\$0.50 per payout to a bank account in USD or EUR (1% for local currency payouts). 0.5% + \$1 per payout to a crypto wallet in USDC or EURC. Crypto Only payments have no payout fee, since funds go directly to your wallet at the time of payment.
Yes. Go to **Settings → Payouts Settings** and update your details at any time. Changes apply to your next withdrawal.
Yes. You can add multiple bank accounts and multiple crypto wallets in **Settings → Payouts Settings**, and choose which one to use each time you withdraw.
Yes. Reach out via [support](https://www.suby.fi/support) and we will see what we can arrange based on your volume and history.
Bank withdrawals go through multiple intermediaries, card networks, issuing banks, acquiring banks, and processors. Each step takes time. Wallet withdrawals are on-chain transactions with no intermediaries, which is why they settle almost instantly once requested.
It's reflected in your Suby Balance. This is not a bank account or a wallet Suby controls, it's a running total of what you're owed, held with our custody partner until you request a withdrawal.
It lets us give you one simple, predictable balance regardless of how your customers pay, whether by card, Klarna, or any supported crypto asset and network.
No, you choose one setting at a time for your account. To switch, update it in \*\*Workspace → Verification → Settlement → Change \*\*before your next payment.
# Stablecoin & Crypto Payments
Source: https://docs.suby.fi/v3-beta/docs/payment/stablecoins-crypto
Crypto payments on Suby settle instantly, wallet-to-wallet. No holding period, no manual reconciliation, no delayed payouts.
## Paying at Checkout
Users can pay in two ways at checkout.
The user connects their wallet, reviews the payment amount, and signs the transaction directly on-chain. This includes MetaMask, Phantom, Rabby, Coinbase Wallet, Binance Wallet, and any other non-custodial wallet.
A QR code and deposit address are displayed at checkout. The user sends funds from any wallet or centralized exchange, no wallet connection required.
The deposit address shown at checkout is not your wallet. Suby creates a dedicated smart account per customer to receive and track funds accurately.
## Settlement
Both payment methods route through the same smart contract logic.
The smart contract receives the payment from the user.
Suby's 1.5% fee is routed to Suby's fee wallet automatically.
The remainder is sent to your configured wallet, instantly, on every transaction.
There is no holding period, no aggregation across transactions, and no manual action required on your end.
## Pricing & Conversion
All product prices are defined in USD. At checkout, Suby calculates the equivalent token amount in real time.
Token conversion rates are powered by Pyth, providing accurate, real-time pricing across all supported assets. The rate is locked at the moment the user initiates payment.
Suby does not use on-chain swaps or variable pricing mechanisms. The amount shown at checkout is the exact amount the user pays.
## Supported Networks & Tokens
Enable or disable tokens individually from **Settings → Payment Methods**.
| Network | Supported Tokens |
| - | - |
| Base | USDC, ETH |
| Ethereum | USDC, USDT, ETH |
| Arbitrum | USDC, ETH |
| BNB Chain | USDC, USDT, BNB |
| Solana | USDC, USDT, SOL |
| Polygon | USDC, USDT0, POL |
| Monad | USDC, USDT0, MON |
| BTC | BTC |
Payouts for fiat payments are settled in USDC on Base, Polygon, Solana, or Arbitrum, depending on your configured payout network in **Settings → Payouts**.
## Verified Smart Contracts
All Suby contracts are publicly deployed and verified on their respective block explorers. Source code is fully auditable, no hidden logic, no upgrade backdoors.
0x8b8f...2550
0xb331...5bbe
0x6cf4...4e1d
0x997c...24e1
0x8b8f...2550
0xb331...5bbe
# Understand Your Balance
Source: https://docs.suby.fi/v3-beta/docs/payment/understand-my-payouts
In Full Payment Methods mode, every payment you receive, cards, Apple Pay, Google Pay, Klarna, bank transfers, or crypto, is credited to your **Suby Balance**. From there, you can withdraw to your bank account or crypto wallet whenever you want.
![Balance 1]()
## Settled Balance
Settled balance is the amount that has cleared all intermediaries and is **ready to withdraw** to your bank account or wallet, whenever you choose. You can find the full breakdown in your dashboard, with the amount, date, and the payments included.
## Pending Balance
Balance stays **pending** as long as the underlying payment has not been settled by all the intermediaries involved in the payment chain: **Visa, Mastercard, banks, and PSPs**.
As soon as a payment is made, it enters a settlement period. During this time, the amount appears as **pending** in your Suby Balance.
Suby automatically checks the settlement status every **6 hours**. As soon as the funds are settled by all intermediaries, the amount moves from pending to **settled** in your balance.
Once settled, the amount is part of your available balance. Withdraw it to your bank account or wallet whenever you want, there's no fixed payout schedule to wait for.
Settlement typically takes **3 to 5 working days**, but timing can vary depending on the card networks, banks, and PSPs involved.
Crypto payments work differently: once auto-converted to USDC on Base, they are credited to your Suby Balance **instantly**, with no settlement delay.
## Withdrawing From Your Balance
Your Suby Balance is not a bank account or a wallet Suby controls, it's a running total of what you're owed. Once an amount is settled, you can withdraw it at any time to your bank account or crypto wallet from **Settings → Payouts Setting**. There's no need to wait for a fixed payout cycle, withdraw as often as you like.
## Why Payments Are Grouped in Your Balance
Instead of tracking every payment individually, Suby consolidates them into a single balance. This keeps your accounting clean and lets you withdraw exactly the amount you want, whenever you want, rather than waiting for individual payments to be paid out one by one. You can always see the full list of payments included in your balance from your dashboard.
## I Have an Issue With My Balance or a Withdrawal
If a withdrawal is taking longer than expected, missing, or your balance is showing an incorrect amount, contact the Suby support team.
Reach us on the support pannel or [email](mailto:contact@suby.fi).
# Errors & responses
Source: https://docs.suby.fi/v3-beta/errors
The response envelope, status codes, and error codes for the v3 API.
## Envelope
```json theme={null}
// success
{ "success": true, "data": { "...": "endpoint-specific payload" } }
// error
{ "success": false, "error": "NOT_FOUND", "message": "Resource not found" }
```
The one exception is `GET /v3/payments/:id/receipt.pdf`, which returns the PDF bytes.
## Pagination
List endpoints are cursor-paginated. Pass `?limit=` (1–100, default 20) and `?cursor=` (the previous `nextCursor`). When `hasMore` is `false`, `nextCursor` is `null`.
```json theme={null}
{ "success": true, "data": { "items": [], "pagination": { "nextCursor": "eyJ…", "hasMore": true } } }
```
## Status codes
| Status | Meaning |
| - | - |
| `200` `201` `204` | OK · Created · No Content |
| `400` | Bad request (e.g. invalid checkout-session signature) |
| `401` | Missing or invalid API key |
| `402` | Charging paused while an outstanding balance is settled |
| `404` | Not found |
| `409` | Wrong state for the action |
| `422` | Validation error · see `data.fieldErrors` |
| `429` | Rate limited |
| `5xx` | Server error |
```json theme={null}
{
"success": false,
"error": "VALIDATION_ERROR",
"message": "Validation failed",
"data": { "fieldErrors": [ { "field": "priceCents", "message": "priceCents is a required field" } ] }
}
```
## Universal codes
`INTERNAL_SERVER_ERROR`, `NOT_FOUND`, `BAD_REQUEST`, `CONFLICT`, `RATE_LIMITED`,
`UNPROCESSABLE_ENTITY`, `UNAUTHORIZED`, `FORBIDDEN`, `TOKEN_EXPIRED`,
`TOKEN_INVALID`, `MFA_REQUIRED`, `ORG_NOT_FOUND`, `MEMBERSHIP_NOT_FOUND`,
`INSUFFICIENT_ROLE`, `ENVIRONMENT_MISMATCH`, `SANDBOX_ONLY`, `LIVE_ONLY`,
`IDEMPOTENCY_KEY_REQUIRED`, `IDEMPOTENCY_KEY_CONFLICT`, `VALIDATION_ERROR`,
`MISSING_FIELD`, `INVALID_ID`.
## Domain codes
`PAYMENT_NOT_FOUND`, `PAYMENT_NOT_REFUNDABLE`, `PRODUCT_NOT_FOUND`,
`CUSTOMER_NOT_FOUND`, `PAYMENT_METHOD_NOT_FOUND`,
`CRYPTO_ONLY_ORG`, `CARD_PAYMENT_BELOW_MIN`, `PROVIDER_NOT_CONFIGURED`, `KYB_NOT_APPROVED`,
`INVALID_PAYMENT_STATUS_TRANSITION`, `CRYPTO_ASSET_NOT_ACCEPTED`,
`CRYPTO_PAYOUT_ADDRESS_MISSING`, `CRYPTO_PAYMENT_BELOW_MIN`,
`CRYPTO_PRICE_FEED_UNAVAILABLE`, `CRYPTO_CURRENCY_NOT_SUPPORTED`,
`BTC_NOT_AWAITING_APPROVAL`, `SOL_PAYER_ADDRESS_REQUIRED`,
`SOL_RPC_UNAVAILABLE`, `EVM_PAYER_ADDRESS_REQUIRED`, `EVM_RPC_UNAVAILABLE`,
`EVM_CONTRACT_NOT_DEPLOYED`, `CRYPTO_AUTOSWAP_TARGET_MISSING`,
`CRYPTO_VAULT_NOT_PROVISIONED`, `CRYPTO_STABLECOIN_DISABLED`,
`CRYPTO_VOLATILE_DISABLED`, `CRYPTO_AUTOSWAP_MODE_NOT_SUPPORTED`.
Crypto charges live on `/v3/crypto/charges` and carry their own codes ·
see the **Crypto** section.
**`CUSTOMER_NOT_FOUND`** (`404`) · no customer with that id belongs to the
account the key authenticates. Same answer as an id that exists under another
account — confirming that someone else's customer is real would itself be a
disclosure — so read it as "not yours", not as "not anywhere".
This endpoint does **not** raise `CUSTOMER_NAME_REQUIRED`. A buyer name is
needed when the payer is present and it travels to the rail with the card they
are typing; an off-session debit sends the stored instrument and the acquirer's
own customer ref, and no identity at all. A customer you only know by email is
chargeable here.
**`CARD_PAYMENT_BELOW_MIN`** (`422`) · the card would be charged less than
1.00 in the payment currency, counted after the discount and with VAT
included. Nothing is created. Crypto has its own per-chain minimum
(`CRYPTO_PAYMENT_BELOW_MIN`).
**`CHARGING_PAUSED_FOR_DEBT`** (`402`) · card charging is suspended until an
outstanding balance is covered, then resumes automatically. Crypto is
unaffected. Not the same as `CARD_LIVE_NOT_ACTIVATED` (never enabled).
`SUBSCRIPTION_NOT_FOUND`, `SUBSCRIPTION_CUSTOMER_NOT_FOUND`,
`SUBSCRIPTION_PRODUCT_NOT_FOUND`, `PRODUCT_NOT_RECURRING`,
`PRODUCT_PRICE_MISSING`, `CUSTOMER_NAME_REQUIRED`, `FIRST_PAYMENT_DECLINED`,
`SUBSCRIPTION_NOT_CANCELABLE`, `CRYPTO_ONLY_ORG`.
A subscription is opened by a checkout session, so `FIRST_PAYMENT_DECLINED`
surfaces on that page rather than as an API error.
Plan change: `SUBSCRIPTION_NOT_MODIFIABLE`, `TARGET_PRODUCT_NOT_FOUND`,
`TARGET_PRODUCT_NOT_RECURRING`, `SAME_PLAN`, `PLAN_CHANGE_CURRENCY_MISMATCH`,
`UPGRADE_REQUIRES_CARD`, `PLAN_CHANGE_DECLINED`,
`NO_SCHEDULED_PLAN_CHANGE`, `PLAN_CHANGE_NOT_CANCELABLE`.
**`SAME_PLAN`** (`409`) is not the way to undo a queued change · it fires
precisely because the subscription is already on that plan. Call
`POST /v3/subscriptions/{id}/cancel-plan-change` instead.
**`NO_SCHEDULED_PLAN_CHANGE`** (`404`) · nothing is queued on this
subscription, or the `scheduledChangeId` you passed does not name what is.
Re-read `scheduledChange` from `GET /v3/subscriptions/{id}`.
**`PLAN_CHANGE_NOT_CANCELABLE`** (`409`) · the change is an immediate upgrade
whose charge is in flight or settled, so dropping the swap would leave the
customer paying for a plan they never get. Refund the charge and change the
plan back.
Expiration date: `SUBSCRIPTION_NOT_MODIFIABLE`, `PERIOD_END_NOT_IN_FUTURE`,
`PERIOD_END_SHORTENING_UNCONFIRMED`.
**`PERIOD_END_SHORTENING_UNCONFIRMED`** (`409`) · the new date is earlier than the
current one, which takes back days the customer already paid for. `data.daysRemoved`
says how many. Send the same request with `allowShorten: true` to confirm.
`PRODUCT_NOT_FOUND`, `PRODUCT_OUT_OF_STOCK`, `PRODUCT_ARCHIVED`,
`RECURRING_REQUIRES_INTERVAL`.
**`PRODUCT_BILLING_INVALID`** (`422`) · the billing fields contradict each
other: a `pay_as_you_go` product carrying a price, a `subscription` with no
`recurringInterval`, an interval on a `onetime` product, or an ACTIVE product
carrying no price. Raised on create and on `PATCH` (against the row merged
with the patch); the message names the rule.
A `priceCents` under `100` (1.00) is refused as a validation error
(`VALIDATION_ERROR`, `422`) on create and on any `PATCH` that sends one. A
product priced lower before this rule stays editable as long as the `PATCH`
leaves `priceCents` out.
**`PRODUCT_BILLING_MODE_LOCKED`** (`422`) · a `PATCH` tried to move a product
into or out of `billingMode: subscription`. The cadence drives running plans
and is not editable, and changing the mode is that same edit by another name.
Create a second product and move subscribers with a plan change.
**`PRODUCT_PRICED_PER_USE`** (`422`) · a `pay_as_you_go` product reached a
surface that prices products by itself — a charging checkout session, a bundle
line, a subscription cycle. Those read an amount off the catalog with no
caller in the loop, and this product has none to read. Sell it with a
`mode=setup` session (the payer authorises the card) and charge each use with
`POST /v3/payments/off-session` and an explicit `priceCents`.
**`PRODUCT_NOT_PRICED_PER_USE`** (`422`) · the mirror of the one above — an
off-session debit (`POST /v3/payments/off-session`) named a product the
catalog already prices, or named none at all. That call carries its own amount
because only a per-use product leaves one undecided: debiting a `onetime`
product this way bills a customer again for something they authorised once, and
a `subscription` product for a cycle Suby's own clock already bills. Both would
succeed at the acquirer. Send `productId` of a `pay_as_you_go` product together
with `priceCents`.
**`PRODUCT_AMOUNT_REQUIRED`** (`422`) · a `pay_as_you_go` charge named no
amount, so nobody decided the price.
**`PRODUCT_CURRENCY_MISMATCH`** (`422`) · a `pay_as_you_go` charge named a
currency the product does not bill in. Refused rather than converted — the
two readings differ by an exchange rate, and one of them debits a real
customer the wrong amount.
**`PRODUCT_PRICE_MISSING`** (`422`) · a catalog-priced product that was never
priced reached a charge. Price it, or declare it `pay_as_you_go`.
**`PRODUCT_PER_USE_UNAVAILABLE`** (`422`) · `billingMode: pay_as_you_go` on an
account that cannot serve it. Per-use bills after the fact, against a credential
stored at checkout, and **two** things have to hold.
First, a method that leaves such a credential: a card, Apple Pay or Google Pay. A
redirect rail authorises one amount on its own site and a crypto deposit is a
transfer, not a mandate — enable one of the three.
Second, an account whose card setup **authenticates** the card as it stores it.
That authentication is what anchors the chain every later usage charge replays;
without it the card is stored, authorises fine, and is refused on the first
charge — days later, with the product already shared. Accounts on a rail that has
no such step cannot create per-use products at all today, and there is nothing to
enable: it opens for them when the rail gains one.
Raised on create and on a `PATCH` that moves a product onto per-use.
**`PRODUCT_METHOD_NOT_PER_USE`** (`422`) · a `pay_as_you_go` product's
`paymentMethods` whitelist named a method its checkout can never offer. That
session only shows card, Apple Pay and Google Pay, so naming a redirect rail
states a choice no payer will see — and a whitelist made only of those resolves
to an empty method list, which is a checkout with nothing on it. The message
names the offending categories.
`CUSTOMER_NOT_FOUND`, `CUSTOMER_ALREADY_EXISTS`,
`CUSTOMER_PAYMENT_METHOD_NOT_FOUND`, `CUSTOMER_PAYMENT_METHOD_REVOKED`.
`CHECKOUT_SESSION_NOT_FOUND`, `CHECKOUT_SESSION_EXPIRED`,
`CHECKOUT_SESSION_INVALID_SIGNATURE`, `CHECKOUT_PRODUCT_INACTIVE`,
`CHECKOUT_SUBSCRIPTION_REQUIRES_RECURRING_PRODUCT`,
`CHECKOUT_METHOD_NOT_AVAILABLE`, `CHECKOUT_QUOTE_UNAVAILABLE`,
`CHECKOUT_ASSET_NOT_ACCEPTED`, `CHECKOUT_ALREADY_COMPLETED`,
`CHECKOUT_EMAIL_REQUIRED`, `CHECKOUT_BILLING_ADDRESS_REQUIRED`,
`CHECKOUT_PAYMENT_FAILED`, `CHECKOUT_CAPTCHA_REQUIRED`.
**`CHECKOUT_SETUP_REQUIRES_PER_USE_PRODUCT`** (`422`) · `mode=setup` named a
product that carries its own price. A setup session stores a card and charges
nothing, so pointing it at a priced product gives the payer a page they
complete and the merchant a saved card where they expected a sale. The mode is
for the product priced per charge (`billingMode: pay_as_you_go`); anything
else is sold with `mode=payment`.
**Writing a code.** `POST` and `PATCH /v3/discount-codes` refuse a code that could
never price:
| Code | Status | Meaning |
| - | - | - |
| `DISCOUNT_CODE_NAME_TAKEN` | `409` | The name already exists in this environment. |
| `DISCOUNT_CODE_PRODUCT_NOT_FOUND` | `404` | A `productIds` entry is not yours, or lives in the other environment. |
| `DISCOUNT_CODE_PRODUCT_CURRENCY_MISMATCH` | `422` | A `FIXED` code prices in one currency but is scoped to a product priced in another. |
A `FIXED` amount is **not** converted: `"200"` with `currency: "EUR"` takes €2 off and
only ever €2. Scoping it to a `$` product is refused here rather than at the
checkout, because this is the moment you can still fix it — a code accepted now and
refused later reaches your buyer, not you. Scope it to products priced in the same
currency, mint one code per currency, or use `PERCENTAGE`, which carries no currency
at all.
A code with no `productIds` covers your whole catalogue and cannot be checked at write
time; it is refused at redemption with `DISCOUNT_CODE_CURRENCY_MISMATCH` when it meets
an order in the other currency.
**Redeeming a code.** A submitted code either prices or is refused with a reason ·
never dropped in silence.
| Code | Meaning |
| - | - |
| `DISCOUNT_CODE_NOT_FOUND` | No such code on this account. |
| `DISCOUNT_CODE_INACTIVE` | Deactivated by the merchant. |
| `DISCOUNT_CODE_EXPIRED` | Past `expiresAt`. |
| `DISCOUNT_CODE_EXHAUSTED` | `maxUses` reached. |
| `DISCOUNT_CODE_CURRENCY_MISMATCH` | `FIXED` code in another currency than the order. |
| `DISCOUNT_CODE_NOT_APPLICABLE` | Scoped to products not on this order. |
| `DISCOUNT_CODES_NOT_ALLOWED` | Promo entry disabled on this checkout. |
`POST /v3/checkout/sessions` returns `422`. The hosted apply-code call returns
`200` with `{ "applied": false, "reason": "…" }` · a payer's typo isn't an API
error. The hosted pay call returns `422` rather than billing full price.
`LICENSE_NOT_FOUND`, `LICENSE_NOT_ACTIVE`,
`LICENSE_ACTIVATION_LIMIT_REACHED`, `LICENSE_INSTANCE_NOT_FOUND`.
**`/v3/licenses/*` is authenticated with your API key**, like every other
endpoint, and the lookup is scoped to your account · you can only ask about
licences you issued. That is what stops the endpoint being an enumeration
oracle: grinding candidate keys through your own credential only ever finds
your own. The consequence is deliberate · your customer's software cannot
call this directly, because that would mean shipping `sk_live` inside it.
Your backend relays the check.
**`LICENSE_NOT_FOUND`** (`404`) · no licence with that key on your account.
The only 4xx `validate` raises: an expired or revoked licence answers `200`
with its `status`, because a 4xx there pushes callers into treating an
expiry as an outage.
**`LICENSE_NOT_ACTIVE`** (`409`, on `activate`) · the licence is expired,
disabled, or was never claimed by the buyer. One code rather than three ·
what the caller does next is the same in all three cases.
**`LICENSE_ACTIVATION_LIMIT_REACHED`** (`409`) · every seat is taken. Free
one with `POST /v3/licenses/deactivate`. The limit is a commercial
guard-rail, not DRM.
**`LICENSE_INSTANCE_NOT_FOUND`** (`404`, on `deactivate`) · no instance with
that id on this licence. Deactivating one already deactivated succeeds.
The headless rail (`/v3/crypto/*`) refuses before it prices, so a charge
never reaches a payer it cannot settle.
| Code | Status | Meaning |
| - | - | - |
| `CRYPTO_NOT_ENABLED` | `422` | The account does not accept crypto at all. |
| `CRYPTO_CHAIN_NOT_SUPPORTED` | `422` | That `chainId` is not one Suby settles on, or not one this account enabled. |
| `CRYPTO_ASSET_NOT_ACCEPTED` | `422` | The chain is fine; that token on it is not accepted. Read `GET /v3/crypto/assets` · it is scoped to the account, not the global catalogue. |
| `CRYPTO_MODE_NOT_SUPPORTED` | `422` | The mode cannot serve that chain · Bitcoin is `qr_deposit` only, having no contracts to sign against. |
| `CRYPTO_PAYER_ADDRESS_REQUIRED` | `422` | `wallet_connect` on EVM or Solana with neither a customer nor a `payerAddress`: there is no address to build a signable transaction from. |
| `CRYPTO_PAYMENT_BELOW_MIN` | `422` | Under the chain's minimum · the network fee would eat the payment. $50 on Bitcoin, $1 elsewhere. Pass the amount to `GET /v3/crypto/assets` and it lists only the chains that clear it. |
| `CRYPTO_SOURCE_NOT_LIFI_SUPPORTED` | `422` | The account converges incoming crypto into one settlement asset, and no bridge can route out of that chain. Same amount on another chain works · `GET /v3/crypto/assets` never lists one that cannot route. |
| `CRYPTO_CURRENCY_NOT_SUPPORTED` | `422` | The fiat `currency` is not one we price from. |
| `CRYPTO_PRICE_FEED_UNAVAILABLE` | `422` | The oracle cannot quote that pair right now. Transient · retry. |
**`CRYPTO_AUTOSWAP_MODE_NOT_SUPPORTED`** (`422`) · the account converges
incoming crypto to a stablecoin on another chain, and `wallet_connect`
cannot do that: the connected wallet settles on the source chain in a single
transaction, leaving nothing in between to convert. Retry with
`mode: "qr_deposit"`. Nothing is wrong with the account's configuration.
# Idempotency
Source: https://docs.suby.fi/v3-beta/idempotency
Retry a POST safely with an Idempotency-Key so a timeout never charges twice.
A request can time out **after** the server created a payment. Retrying blindly would charge twice. Send an `Idempotency-Key` header and the retry replays the original response instead of running again.
```bash theme={null}
curl https://api.suby.fi/v3/payments/off-session \
-H "X-Suby-Api-Key: sk_live_…" \
-H "Idempotency-Key: 5f3b9c2e-1a4d-4f2b-9c31-7e2a1b6d8c04" \
-H "Content-Type: application/json" \
-d '{ "offSession": true,
"customer": { "id": "cus_…" }, "customerPaymentMethodId": "pi_…",
"productId": "pro_…", "priceCents": "999" }'
```
Optional, but recommended on every state-changing `POST` · a duplicated debit is the one mistake a retry can make that the buyer notices. Use a UUID v4: one per logical operation, reused on retry.
## Behaviour
| Situation | Result |
| - | - |
| Same key, same request | Original response replayed · same status, same body. |
| Same key, different body or path | `422 IDEMPOTENCY_KEY_CONFLICT` |
| Same key, first request still running | `409 IDEMPOTENCY_KEY_CONFLICT` · wait and retry. |
| Same key, older than 24 h | Treated as new · the operation runs again. |
`5xx` responses are **not** cached: the key is released so you can retry. `2xx` and `4xx` are cached.
## Scope
| | |
| - | - |
| **Scope** | Per account and environment · a sandbox and a live key never collide. |
| **Binding** | Method + path + body. |
| **Retention** | 24 hours. |
| **Methods** | `POST` only. `PATCH` is not deduplicated. |
| **Max length** | 255 characters. |
## Not the same as `externalRef`
`Idempotency-Key` is a per-**request** token that deduplicates a retried HTTP call, and expires in 24 h. `externalRef` is your **business** reference (an order id) · it can appear on several payments and never deduplicates anything.
# Introduction
Source: https://docs.suby.fi/v3-beta/introduction
The Suby.fi v3 merchant API · accept cards, APMs and crypto payments.
Suby.fi takes one-time and subscription payments by **card/APM** and **crypto**, priced in **USD** or **EUR**, and can grant access (Discord, Telegram, files, licences) automatically once a payment lands.
## Base URL & environments
All routes live under `/v3`, e.g. `https://api.beta.suby.fi/v3/payments`. Authenticate with the `X-Suby-Api-Key` header · the environment comes from your key prefix (`sk_live_…` / `sk_sandbox_…`), not a header.
During the beta the API is served at **`api.beta.suby.fi`**; `api.suby.fi` still
serves [v2](/v2/introduction). Update your base URL at GA.
## How money moves
**Every payment starts with a checkout session.** You describe what to charge, we host the page that collects the card. That is the whole integration · and it is why no card data ever reaches your servers.
```
POST /v3/checkout/sessions → cs_… → send the buyer to its url
```
The buyer picks the method on the page: cards and APMs (`CARD`, `APPLE_PAY`, `GOOGLE_PAY`, `KLARNA`, `IDEAL`, `BANCONTACT`, `TWINT`, `BLIK`, `AFFIRM`, `ALMA`, `BILLIE`, `SCALAPAY`, `MULTIBANCO`, `PAYPAL`, `SEPA_DIRECT_DEBIT`, `ACH_DIRECT_DEBIT`) or crypto. Which ones appear is your account configuration, never the acquirer's.
A session on a product that carries a `recurringInterval` also **opens the subscription** and bills its first cycle. Card renewals then run off-session with smart retry; crypto renewals go through a per-cycle email. You never call the API for cycle N+1.
### The two exceptions
`POST /v3/payments/off-session` exists for the cases a hosted page cannot serve:
| | When |
| - | - |
| **Off-session debit** | Charging a card the buyer already stored with us · metered billing, a top-up, a threshold crossed. Needs `offSession: true` and the `pi_…` from `GET /v3/customers/{id}/payment-methods`. |
| **Crypto** | `method=CRYPTO` returns a deposit address or wallet-connect calldata. No card data is in play. |
A card charge with the buyer present is refused there. There is no tokenization SDK, and no way to bring your own token.
## Crypto networks
Payments settle **same-chain** into stablecoins. Which assets your account accepts is set per environment in your account configuration.
| Network | `chainId` | Assets |
| - | - | - |
| Bitcoin | `21` | BTC |
| Ethereum | `1` | ETH, USDC, USDT |
| Base | `8453` | USDC, EURC, ETH |
| Arbitrum | `42161` | USDC, ETH |
| BNB Chain | `56` | BNB, USDC, USDT |
| Polygon | `137` | POL, USDC, USDT0 |
| Solana | `101` | SOL, USDC, USDT |
| Monad | `143` | MON, USDC, USDT0 |
Sandbox is limited to Base Sepolia (`84532`, USDC/ETH).
## Get started
1. Create an account at [dashboard.suby.fi](https://dashboard.suby.fi).
2. Generate an API key in [settings](https://dashboard.suby.fi/dashboard/settings) · shown once.
3. Create a product, then a checkout session.
4. Register a webhook endpoint **in the dashboard**, and verify signatures on your side.
5. Accepting cards? Complete business verification in the dashboard onboarding.
Product to first payment, in a few requests.
Keys, environments, sandbox.
Events, payloads, signature verification.
Every endpoint and field.
# Quickstart
Source: https://docs.suby.fi/v3-beta/quickstart
Create a product and take your first payment with the v3 API.
Zero to a working payment in four requests. Use a `sk_sandbox_…` key · nothing touches real money.
Omit `recurringInterval` for a one-time product; set it for a subscription plan.
```bash theme={null}
curl -X POST https://api.beta.suby.fi/v3/products \
-H "Content-Type: application/json" \
-H "X-Suby-Api-Key: sk_sandbox_your_key" \
-d '{ "name": "Pro Plan", "priceCents": "999", "currency": "EUR" }'
```
`data.id` is your `pro_…`.
Mint a `cs_…` token and redirect the buyer to its `url`.
```bash theme={null}
curl -X POST https://api.beta.suby.fi/v3/checkout/sessions \
-H "Content-Type: application/json" \
-H "X-Suby-Api-Key: sk_sandbox_your_key" \
-d '{
"mode": "payment",
"productId": "pro_abc123",
"successUrl": "https://your-app.com/success",
"cancelUrl": "https://your-app.com/cancel"
}'
```
Test card `4242 4242 4242 4242`, any future expiry, any CVC.
Add your destination in [dashboard settings](https://dashboard.suby.fi/dashboard/settings)
and store the `whsec_…` secret it shows once · you need it to
[verify signatures](/v3-beta/webhooks).
In your handler, verify the signature and grant on the right event ·
[which one](/v3-beta/webhooks#access-granting) depends on the payment method.
## Charge without a hosted page
Two calls, in this order, and only for the pay-as-you-go case · metered billing, a top-up, a threshold crossed.
**1. Store the card.** A `setup` session takes no amount and charges nothing.
```bash theme={null}
curl -X POST https://api.beta.suby.fi/v3/checkout/sessions \
-H "Content-Type: application/json" \
-H "X-Suby-Api-Key: sk_sandbox_your_key" \
-d '{
"mode": "setup",
"customer": { "email": "buyer@example.com" },
"successUrl": "https://your-app.com/saved",
"cancelUrl": "https://your-app.com/cancel"
}'
```
Send the buyer to `data.url`. Once they are through, read the stored card:
```bash theme={null}
curl https://api.beta.suby.fi/v3/customers/cus_abc123/payment-methods \
-H "X-Suby-Api-Key: sk_sandbox_your_key"
```
**2. Debit it later**, with nobody in front of the screen.
```bash theme={null}
curl -X POST https://api.beta.suby.fi/v3/payments/off-session \
-H "Content-Type: application/json" \
-H "X-Suby-Api-Key: sk_sandbox_your_key" \
-d '{
"offSession": true,
"customer": { "id": "cus_abc123" },
"customerPaymentMethodId": "pi_abc123",
"productId": "pro_abc123",
"priceCents": "1250",
"displayName": "April usage"
}'
```
A card charge with the buyer **present** is refused here. Collecting a card needs
a page that renders card fields, and that page is ours · so there is no way to
hand this endpoint a card token, and no card data ever reaches your servers.
Every parameter and response field.
# Webhooks
Source: https://docs.suby.fi/v3-beta/webhooks
Receive and verify signed event notifications from Suby.fi.
Suby sends signed `POST` webhooks to the endpoints you register in [dashboard settings](https://dashboard.suby.fi/dashboard/settings). Each endpoint has its own `whsec_…` secret, shown once at creation and on rotation.
Subscribe to specific events or to all of them, rotate the secret, and disable an endpoint from the same screen. Choosing where events go is an account setting, not an integration surface · but the events themselves are the backbone of the integration, so verify every one.
## Events
### Payments
| Event | When |
| - | - |
| `payment.succeeded` | The sale went through · card captured, or crypto settled on-chain. On crypto this fires once the settlement transaction is accepted · the `SubyPayment` split for a payment that stays on its chain, the bridge transaction for one we convert · not when the deposit merely lands. Typically a few seconds after the deposit; capped, so a slow or stuck settlement still emits within \~35s. |
| `payment.failed` | Didn't go through. `status` tells you which: `FAILED` (technical) vs `DECLINED` (issuer refusal). |
| `payment.refunded` · `payment.partially_refunded` | Refunded in full / in part. |
**There is one success event, and it is `payment.succeeded`.** A hosted checkout
completing, a `/v3/crypto/charges` deposit clearing and an off-session debit
capturing all emit that same event, so one handler covers every way a payment can
be taken · there is no separate `checkout.*` family to subscribe to.
Nothing fires between the payer acting and the money being taken: every card charge
captures immediately, so a payment is never left authorized-and-waiting.
`payment.succeeded` is the acquirer confirming the charge, not the money reaching
your bank. That second step is `payout.completed`.
### Subscriptions
| Event | When |
| - | - |
| `subscription.created` | **Activated** · fires when the first cycle confirms, not at API-create time. A declined first charge never fires it. |
| `subscription.renewed` | A cycle was charged. |
| `subscription.past_due` | Renewal failed, dunning started. |
| `subscription.updated` | The subscription changed without ending · a cancellation was **scheduled** (`cancel_at_period_end` is now `true`, `expires_at` says until when), a plan change was applied, or the expiration date was changed (`expires_at` is the new date). |
| `subscription.canceled` | Canceled · now, or at the period boundary. |
| `subscription.expired` | Ended. Access removed. |
**A plan change is announced when it lands, not when it is asked for.**
`POST /v3/subscriptions/{id}/change-plan` answers `202` and the swap happens later · on
the upgrade charge completing, or at the next renewal for a period-end downgrade.
`subscription.updated` fires at that moment, with `productId` naming the new plan. Read
`GET /v3/subscriptions/{id}` in the meantime: while the change is queued it comes back
under `scheduledChange`, and once applied that field is `null`. A period-end downgrade
also announces itself as the `subscription.renewed` of the cycle that bills it.
**A cancellation is two events, not one.** Scheduling one — from the dashboard, the
customer's `/manage` portal, or `POST /v3/subscriptions/{id}/cancel` with the default
`atPeriodEnd: true` — fires `subscription.updated` straight away: the subscription is
still `ACTIVE` and still entitles the customer, but `cancel_at_period_end` is `true` and
`expires_at` is the last day they have. **This is the churn signal · act on it here.**
`subscription.canceled` comes later, when the period actually ends and the access is
revoked, and on an annual plan that is a year after the customer made up their mind.
Cancelling with `atPeriodEnd: false` skips the wait: `subscription.canceled` only.
Suby drives renewals · you never call the API for cycle N+1.
Access never outlives the period that was paid for: when a renewal is not paid on its due date, the accesses it grants are revoked right away (`access_grant.revoked`), and given back automatically if a later payment for that cycle succeeds.
* **Card / wallets** · off-session smart retry, all within 72h of the due date: **monthly and yearly plans get 4 attempts** (due date, +6h, +24h, +72h), **weekly plans 3** (due date, +6h, +24h), **daily plans 2** (due date, +6h). The access is revoked on the **first** refusal and comes back when a retry succeeds. Soft declines retry; hard declines (stolen card, closed account) end it **immediately, whatever attempts remain** · the credential is unusable, so a retry is a guaranteed second refusal. A third category, `AUTHENTICATION_REQUIRED`, means the issuer wants the cardholder to confirm the card: the schedule keeps running, but only the customer clears it · we email them a link to do so. State on the `Subscription`: `renewalAttempt`, `nextRenewalAttemptAt`, `lastDeclineCategory`.
* **Crypto** · the customer re-deposits through a renewal link, sent by email and on Discord/Telegram **48h before the due date** (24h for plans shorter than a month). With no deposit by the due date, the subscription moves to `past_due` and its accesses are revoked; it stays renewable for 2 more days, and paying in that window renews it in place and gives the accesses back. After that it expires.
* **Several purchases, one access** · before revoking, Suby checks that no other live purchase grants the same access to the same person · including one made under another email with the same Discord or Telegram account. If one does, the entitlement ends but the role or membership stays, and the holder gets no renewal reminder, cooldown role or expiry notice for it · nothing they hold is at risk.
### Disputes
A chargeback does **not** move the payment's `status` · the sale did complete, and
rewriting that would lose it. These events are the only notification you get.
| Event | When |
| - | - |
| `dispute.opened` | The cardholder's bank raised a chargeback. `evidence_due_by` is your deadline to respond; contest it from the dashboard. |
| `dispute.won` | The defense was accepted · the amount is reinstated on your balance. The chargeback fee is **not** returned. |
| `dispute.lost` | The defense was rejected · the funds stay withdrawn and `fee_cents` names the fee debited. |
The payload is the dispute, not the payment: `object: "dispute"`, with `payment_id`,
`status`, `reason` (the scheme's own code, e.g. `fraudulent`), `amount_cents` (which
can be less than the payment on a partial chargeback), `currency`, `evidence_due_by`,
`resolved_at` and `fee_cents`.
`dispute.expired` · a defense window missed · can be subscribed to but is not
emitted yet. Treat a missed window as a `dispute.lost` today.
### Access
| Event | When |
| - | - |
| `access_grant.created` | Claimable by the buyer. One event **per access** · a bundle of three fires three. |
| `access_grant.claimed` | The buyer collected it. Explicit for every kind, files and links included. |
| `access_grant.revoked` | Entitlement ended · refund, chargeback, subscription over, manual revoke. |
| `access_grant.failed` | Delivery failed (bot removed, repository gone). Stays retryable. |
**The delivered material is never in the payload** · a licence key or a single-use invite doesn't belong in something stored, retried and logged. You get identifiers only: `id`, `customer_id`, `source_ref`, `kind`, `status`.
`source_ref` is what the entitlement hangs off · `pay_…` for a one-off, `sub_…` for a subscription. Stable across renewals, so use it to correlate with your own order.
`access_grant.revoked` means the **entitlement** ended, not necessarily that the
customer lost the access · they may still hold it through another live purchase.
Read their remaining grants before cutting them off.
### Customers, payment methods, payouts
| Event | When |
| - | - |
| `customer.created` · `customer.updated` · `customer.deleted` | Customer lifecycle. |
| `payment_method.attached` | A card was stored · a checkout session in `mode: setup`, or one sent with `savePaymentMethod: true`. |
| `payment_method.detached` | Saved method revoked. |
| `payout.completed` · `payout.failed` | Merchant payout outcome. |
## Payload
Every delivery shares one envelope. The kind is `type`; the resource sits under `data` with its own `object` discriminator.
| Field | |
| - | - |
| `id` | Event id (`evt_…`). Stable across retries · dedupe on it. |
| `type` | e.g. `payment.succeeded`. |
| `createdAt` | ISO-8601 of the event, not the delivery. |
| `api_version` | Version the endpoint was created against. |
| `livemode` | `true` = live, `false` = sandbox. |
| `data` | The object. Carries `object`; `status` is lowercase. |
```json theme={null}
{
"id": "evt_1a2b3c",
"type": "payment.succeeded",
"createdAt": "2026-07-13T20:38:06.690Z",
"api_version": "2026-05-12",
"livemode": true,
"data": { "object": "payment", "id": "pay_…", "status": "completed" }
}
```
Branch on the envelope `type` (or the `X-Webhook-Event` header) · never on the `data` shape alone.
### `items` · what was bought
Every `payment.*` event carries `items`, the basket as it was charged, frozen at that moment:
```json theme={null}
"items": [
{ "product_id": "pro_…", "name": "Rulebook", "quantity": 1, "unit_price_cents": 1990 },
{ "product_id": "pro_…", "name": "Dice set", "quantity": 2, "unit_price_cents": 1990 }
]
```
A single-product charge is a basket of one, so read `items` whatever the payment: `product` names
only the simple case and stays `null` for a payment link that charges several products. `product_id`
is `null` on an ad-hoc amount (a price and a label, no catalogue entry). Prices are in the payment's
`currency`, and a discount applies to the payment total · the lines keep their listed unit price, so
they do not necessarily sum to `amount_captured_cents`.
### `fee_breakdown` on a crypto payment
A cross-chain crypto sale is announced the moment the payer's deposit is irreversible · the bridge
fills and the on-chain split takes Suby's cut minutes later. `platform_fee_cents` and `net_cents`
are nonetheless in that event: they are computed at the rate you were quoted, which is the rate the
split then executes. `settled_at` stays null until the funds land, and `tax` is always null on a
crypto charge (nothing is added on top of your price, whatever your settlement mode).
### `metadata` is yours alone
`metadata` returns exactly the keys you sent at checkout, and nothing else · Suby's own routing ids
are never mixed into it. What it used to carry has proper fields: `checkout_session_id` for the
session that minted the payment, `bundle_id` for the payment link it came from.
### `payment_method` · one flat shape
```json theme={null}
"payment_method": { "type": "card", "brand": "visa", "last4": "4242" }
"payment_method": { "type": "klarna", "brand": null, "last4": null }
"payment_method": { "type": "apple_pay", "brand": "mastercard", "last4": "5100" }
```
| Field | |
| - | - |
| `type` | What the payer used · `card`, `apple_pay`, `google_pay`, `klarna`, `ideal`, `bancontact`, `twint`, `blik`, `affirm`, `alma`, `billie`, `scalapay`, `multibanco`, `paypal`, `cash_app_pay`, `sepa_direct_debit`, `ach_direct_debit`, `crypto`. Branch on this and nothing else. |
| `brand` | Card network (`visa`, `mastercard`, `amex`, `discover`, `diners`, `jcb`, `unionpay`, `unknown`). Null for a method that has no network, and null on a card whose acquirer did not tell us · `type` still says it was a card. |
| `last4` | The mask the method exposes: a card's PAN, a SEPA/ACH debit's account. Null for a method that masks nothing. |
| `crypto` | Chain-side facts. Present **only** when `type` is `crypto`. |
A wallet is a token over a card, so `apple_pay` and `google_pay` carry the underlying card's
`brand` and `last4`. An Amex arrives as `type: "card"` with `brand: "amex"` · the network is a
brand, never a method of its own.
`payment_method` is `null` in one case only: no instrument was ever bound, which is what a payment
refused before authentication looks like.
### `payment_method.crypto` · the payer's side
On a crypto payment the `crypto` block describes **what the payer sent**: `chain_id`,
`token_symbol`, `token_decimals`, `token_amount`, `tx_hash` and `from_address` are all theirs.
Where the funds are *heading* is on the payment object itself · `settlementChainId`,
`settlementAsset`, `settlementChain` · because on a converging account the two sides differ on
almost every payment, and the destination amount does not exist yet when the sale is confirmed.
Format `token_amount` with `token_decimals`; never with the destination asset's.
### `receipt_url`
The hosted receipt for a paid payment · the same page your buyer's receipt email links to. Present on
`payment.succeeded`, `payment.refunded` and `payment.partially_refunded`; `null` elsewhere, and
`null` on a deployment with no hosted checkout configured.
## Verifying
| Header | |
| - | - |
| `X-Webhook-Event` | The event type. |
| `X-Webhook-Timestamp` | Unix seconds. |
| `X-Webhook-Signature` | `v1=` |
HMAC-SHA256 of `` `${timestamp}.${rawBody}` ``, keyed with your endpoint secret.
```typescript theme={null}
import crypto from "node:crypto";
function verifySubyWebhook(req, secret: string): boolean {
const timestamp = req.headers["x-webhook-timestamp"] as string;
const signature = req.headers["x-webhook-signature"] as string; // "v1="
const rawBody = req.rawBody; // exact received bytes
if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;
const expected =
"v1=" +
crypto.createHmac("sha256", secret).update(`${timestamp}.${rawBody}`).digest("hex");
return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}
```
Use the **raw body bytes** · don't re-serialize parsed JSON. In Express, use
`express.raw()` on the webhook route or stash `req.rawBody` via `verify`.
## Responding
Return `2xx` in under 5s. Non-2xx is retried with backoff, so make your handler idempotent · the same event can arrive twice.
## When to grant access
| Method | Grant on | Revoke on |
| - | - | - |
| **Card** | `payment.succeeded` | `payment.refunded`, `dispute.opened`, `subscription.expired` |
| **Crypto** | `payment.succeeded` | `payment.refunded`, `subscription.expired` |
One event grants on both rails · that is the point of there being a single success
event. Do **not** grant on `payment.failed`'s absence or on a checkout redirect
landing: the payer reaching your `successUrl` means their browser followed a
redirect, not that the charge captured.
Revoke on `dispute.opened`, not on `dispute.lost`: the money is already gone when the
chargeback is raised, and the defense can take months. If you win it,
`dispute.won` is your signal to grant again.
If you let Suby deliver the access (Discord, Telegram, licences, files, links), you do
not need this table at all · `access_grant.revoked` already fires for every one of
these cases, and the entitlement is cut on our side.
# Update a customer
Source: https://docs.suby.fi/v3-beta/api-reference/customers/update-a-customer
/v3-beta/api-reference/openapi.yaml patch /v3/customers/{id}
Update name, billing address and/or business status. Email is immutable. Send `billingAddress: null` to clear it.
# Free a machine's seat
Source: https://docs.suby.fi/v3-beta/api-reference/licence-key/free-a-machines-seat
/v3-beta/api-reference/openapi.yaml post /v3/licenses/deactivate
Idempotent · deactivating an already-deactivated instance succeeds and returns it. Only an instance that never existed on this licence is a `404`.
# Is this licence key still valid
Source: https://docs.suby.fi/v3-beta/api-reference/licence-key/is-this-licence-key-still-valid
/v3-beta/api-reference/openapi.yaml post /v3/licenses/validate
Authenticated with your API key and scoped to your account · you can only ask about licences you issued, which is what keeps this from being an enumeration oracle. Your customer's software cannot call it directly (that would ship `sk_live` inside it) · your backend relays the check.
`instanceId` is optional · with it, `instance` describes that machine's seat. An unknown instance is not an error, it comes back `null`.
An expired or revoked licence answers `200` with its `status` · only a key that is not on your account is a `404`. Cache for a few minutes rather than calling on every request.
# Take a seat for one machine
Source: https://docs.suby.fi/v3-beta/api-reference/licence-key/take-a-seat-for-one-machine
/v3-beta/api-reference/openapi.yaml post /v3/licenses/activate
You name the instance, **Suby mints its id** · stored from `instance.id` and passed back to `deactivate` and `validate`. A caller-chosen id would make the activation limit a suggestion: a client could send a fresh one on every launch and never consume a seat.
That limit is a commercial guard-rail, not DRM · it makes casual sharing visible and inconvenient, it does not stop a determined user.
# List saved payment methods
Source: https://docs.suby.fi/v3-beta/api-reference/payment-methods/list-saved-payment-methods
/v3-beta/api-reference/openapi.yaml get /v3/customers/{id}/payment-methods
# Revoke a saved payment method
Source: https://docs.suby.fi/v3-beta/api-reference/payment-methods/revoke-a-saved-payment-method
/v3-beta/api-reference/openapi.yaml delete /v3/customers/{id}/payment-methods/{pmId}
Idempotent · revoking an already-revoked method still returns 204.