# 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} # 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. # 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. # 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 # 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 # 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 alert / reserve / 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 0.7 / 0.9 / 1.0% thresholds 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. * Suby uses **auto-refund on flagged transactions**: payments that look likely to be disputed (fraud signals, pre-dispute alerts, repeat "friendly fraud" patterns) are refunded automatically before the cardholder escalates, so the transaction never becomes a chargeback at all. * Suby, not you, decides how a dispute is represented. 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 1.0% line, 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 | | Alert / reserve / termination | 0.7% / 0.9% / 1.0% | 0.7% / 0.9% / 1.0% | | 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, deliberately strict) | You | | Auto-refund to prevent disputes | Yes, applied proactively | 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% alert threshold, 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 / 0.75 / 1.0% 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. 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 three stages, well before Visa or Mastercard would ever step in themselves. You're flagged internally and notified: dashboard warning plus email. Nothing is held yet; this is your signal to act before it compounds. Suby starts holding back a reserve on your payouts to cover expected dispute losses while you bring the rate back down. Processing is suspended. At 1.0% you're still well under Visa's and Mastercard's own "excessive" lines. Suby stops early on purpose. See [Visa & Mastercard Dispute Programs](/v3-beta/docs/education/visa-mastercard-dispute-programs) for why. | Range | Status | | ------------ | ------------ | | 0% – 0.5% | Healthy | | 0.5% – 0.75% | Alert | | 0.75% – 1.0% | Reserve held | | 1.0%+ | Suspended | Visa and Mastercard don't consider a merchant "excessive" until 1.5%. Suby's termination line sits a third below that, at 1.0%, 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): 0.5% alert, 0.75% reserve, 1.0% termination. 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 thresholds on [Suby's Dispute Thresholds](/v3-beta/docs/education/suby-dispute-thresholds) are 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. Newcheckout ## 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 They complete payment with a card or stablecoin/crypto Newcryptocheckout Crypto The paid role is granted instantly and they receive a confirmation inside Discord. Ne On renewal, nothing changes, access is maintained automatically. Renew On cancellation or failed payment, the role is revoked and they are notified. 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. Newcheckout ## 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 If a renewal payment fails, Suby automatically retries the charge over the following days and notifies the customer to update their payment method. If the payment remains unresolved, the subscription is cancelled and access is revoked. ## 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. Newqrcodecheckout 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 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 The Suby bot assigns the paid role instantly. If the customer is not yet in your server, they receive an invite automatically. 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 The role is revoked automatically. The member is notified inside Discord. Remove ## Renewal & Access Removal If a card renewal fails, Suby retries the charge over the following days. If the payment remains unresolved, the role is revoked and the member is notified. Suby sends a renewal reminder to the member before their access period ends. If the subscription is not renewed, the role is removed automatically after the reminder period. 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 when a payment fails or a crypto subscription is not renewed after the reminder period. The user is removed without any manual action. 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 renewal reminders directly inside Telegram before access expires. If the payment is completed, 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. # Use with AI Source: https://docs.suby.fi/v3-beta/docs/introduction/AI Integrate your product into your app in one click with your favorite AI builder. ## One-click integration Launch your favorite AI builder with the full Suby integration prompt already written. It scaffolds your database, API calls, webhook handler, and UI, so all you have to do is paste your API keys. Spin up a full Supabase + webhooks integration in one click. Open Claude with the full integration prompt pre-loaded. Open ChatGPT with the full integration prompt pre-loaded. After your AI finishes, add `[PRODUCT]_API_KEY` and `[PRODUCT]_WEBHOOK_SECRET` as secrets, then paste the webhook URL it gives you into **Suby Dashboard → Settings → Webhooks**. *** ## Just load the docs Want to ask questions instead of building? Open a chat with the full Suby documentation loaded as context. Load the full Suby docs into a Claude conversation. Load the full Suby docs into a ChatGPT conversation. *** ## Plain text If your tool accepts a URL or raw text, paste one of these directly into the context window. | Format | URL | Best for | | --------- | ------------------------------------ | ------------------------------ | | Summary | `https://docs.suby.fi/llms.txt` | Quick context, token-efficient | | Full docs | `https://docs.suby.fi/llms-full.txt` | Deep integration work | *** ## After the AI finishes Grab them from your [Suby dashboard](https://dashboard.suby.fi/dashboard/settings) and save them as: * `[PRODUCT]_API_KEY` * `[PRODUCT]_WEBHOOK_SECRET` Copy the webhook URL your AI generated and paste it into **Suby Dashboard → Settings → Webhooks**. Use Suby's test credentials to run a full end-to-end flow, verify the webhook fires, and confirm everything updates correctly in your database. Swap test credentials for production credentials and you're ready to ship. *** ## What the AI will know Once loaded, your assistant has full context on: Authentication, core resources, and all available operations. All events, payload structure, and signature verification. The main capabilities of Suby and how to use them. SDKs, frameworks, and platform-specific adapters. Resources, relationships, and recommended schema. Rate limits, quotas, and billing details. For complex integrations, use `llms-full.txt` for maximum context. For quick Q\&A, the summary `llms.txt` is faster. # Account Reviews Source: https://docs.suby.fi/v3-beta/docs/introduction/account-reviews Learn how account reviews work on Suby, and how to make yours successful. As a **Merchant of Record**, Suby acts as the reseller of your digital goods and services. All accounts must pass a compliance review before going live. This involves verifying legitimacy, preventing fraud, and ensuring alignment with our acceptable use guidelines. ## Checklist Your product is ready for production. No fake reviews, inflated user counts, or misleading testimonials on your website. Both pages must be publicly accessible on your website. We can understand what you sell from your landing page without guessing. Pricing must be visible and accessible to users before checkout. A reachable, branded email (e.g. `support@yourproduct.com`) not a generic Gmail address. Your product name doesn't infringe on existing trademarks or create consumer confusion. If your product generates AI images, video, or audio, NSFW filters are mandatory. *** ## How to submit Navigate to **Balance → Payout Account** in your Suby dashboard to start the review process. You'll need to provide: * Your full name and/or business entity name * Your store or product name * The URL of your product or landing page * A description of your business and how it operates * A description of the products you intend to sell through Suby * Your country of tax residency (or country of incorporation for business entities) *** ## The review process Reviews are typically completed within **24 hours**. During peak periods, up to 48 hours. Go to **Balance → Payout Account** and fill in your business and product details. Our team reviews your website, product, and submitted information. No action needed on your end. You'll receive an email confirmation. Payouts are now enabled. ### Common reasons for change requests These are the most frequent issues that delay or block account approval. | Issue | Fix | | ---------------------- | ------------------------------------------------------------------ | | Support email mismatch | Update it in **Settings → Business Details** to match your website | | Website not accessible | Make sure your site is live, public, and not returning errors | | Missing legal pages | Add a Privacy Policy and Terms of Service | | False information | Remove fake reviews, testimonials, or inflated metrics | | Product not ready | Use test mode until your product is live | *** ## Accepted products Suby supports digital goods and services that can be fulfilled online. Examples include: *** ## Prohibited & restricted products The following are **not permitted** on Suby. Attempting to sell these will result in suspension. This list is non-exhaustive. Our partners and providers may flag additional categories at any time. * Sexually-oriented or pornographic content of any kind * Face-swap, deepfake, and face-manipulation tools or services * IPTV services * Spyware or parental control apps * Products for which you do not hold proper IP rights * Marketplaces where you use Suby to resell other people's products * Dating sites * Counterfeit goods * Illegal or age-restricted products (drugs, alcohol, tobacco, vaping, puffs, nicotine pouches) * Regulated products (CBD, gambling, weapons, sweepstakes, lotteries, get-rich-quick schemes) * Regulated services (real estate, mortgage, lending, legal, banking, debt relief, warranties) * Pharmacies, pharmaceuticals, nutraceuticals, steroids, SARMs, peptides, hormones * Homework or essay mills * MLM, pyramid schemes, or IBO schemes * Cryptocurrencies, NFTs, tokens, ICOs, and mining-as-a-service * Forex, trading signals, copy-trading, prop firms, and high-yield investment programs * Crowdfunding, donation collection, fundraising platforms, and cash-advance services * Gift cards, prepaid cards, e-money, mobile top-ups, and money transfer services * Travel agencies, ticket resale, and timeshare offers * High-ticket coaching or mentoring promising guaranteed income or results * Dropshipping with delivery times exceeding 30 days * Auto-renewing subscriptions without clear and explicit consent (negative option billing) * Pre-orders or crowdfunded products that are not yet manufactured or in stock * Fake or fraudulent document generators (invoices, payslips, IDs, diplomas, proof of address) * Game cheats, hacks, bots, boosted accounts, and unauthorized in-game currency * Scraped data, email lists, lead databases, and personal data marketplaces * Sale or rental of social media, streaming, or online accounts * Sale of followers, likes, views, comments, or any artificial engagement * DRM circumvention, SIM unlocking, and jailbreak-as-a-service * Weapons, ammunition, weapon parts, and lethal tactical gear * Live animals and products derived from protected species (CITES, ivory, exotic wildlife) * Extremist, hateful, or violence-inciting content * Occult or esoteric services (psychic readings, spell casting, curse removal, love spells) * Kratom, kava, poppers, research chemicals, and unapproved nootropics * Contact lenses, medical devices, and direct-to-consumer diagnostic tests * Stresser, booter, or DDoS-for-hire services * 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 These categories require **strict due diligence**. Approval is not guaranteed · contact us before submitting. * Services of any kind (marketing, design, web development, consulting) * Job boards * Newsletter advertising * Social media advertising Reach out to [support@suby.fi](mailto:support@suby.fi) with a description of your product before you apply. *** ## Customer support requirements Visible on your website and in customer receipts. Must match your product domain. Users must be able to cancel directly from your product via the Suby API or Customer Portal. Respond to customer requests within 3 business days, or Suby may issue refunds on your behalf. *** ## Ongoing monitoring Suby continuously monitors all active accounts, not just at onboarding. Random audits are performed at any time and are typically completed within hours. We look at: * Product description and accuracy * Pricing and payment methods * Customer support and contact information * Website and landing page * Risk scores across historical transactions * Refund and chargeback ratios If we detect suspicious activity, your account may be placed under review without prior notice. Maintaining compliance at all times, not just during the initial review, is your responsibility as a merchant. # Quickstart Source: https://docs.suby.fi/v3-beta/docs/introduction/quickstart Accept your first payment in under 5 minutes. This guide walks you through enabling a payment method, creating a product, and collecting your first payment. ## Before you begin Make sure you have a Suby account. If not, [sign up here](https://dashboard.suby.fi/). New accounts go through a quick review before going live. [Learn more about the review process](/v3-beta/docs/merchants/account-review-process). ## Step 1: Enable a payment method Suby supports two payment methods. You can enable one or both. Visa, Mastercard, Amex, and all major cards. Higher conversion rates, automatic payouts, supports one-time payments and subscriptions. Reviews in 24h: [Apply for card payments](https://dashboard.suby.fi/) USDC, USDT, ETH, SOL, and BNB. Go live in minutes, accept worldwide, non-custodial, funds go directly to your wallet. Active by default: [Enable stablecoin payments](https://dashboard.suby.fi/) Onboarding 2 ## Step 2: Create a product Everything is configured in one place. From your [dashboard](https://dashboard.suby.fi/), click **Create product** and set up: * **Name**: what you're selling (e.g. "Pro Plan", "Premium Community", "Design Templates") * **Billing type**: one-time or recurring (monthly / yearly) * **Price**: in fiat (USD, EUR...) * **Integration**: how customers get access after paying (PayLink, API, Discord, or Telegram) You can create multiple products with different billing types, prices, and integrations, for example a monthly plan and a yearly plan. ## Step 3: Choose your integration The fastest way to start and the best option for testing or accepting payments without writing any code. Generate a checkout link and share it anywhere: your website, a Discord message, an email, a bio link. 1. From your product page, click **Generate PayLink** 2. Copy the link 3. Share it: your customers can pay immediately PayLinks can be combined with the API for more complex flows: use PayLinks for quick sales and the API for subscription management or custom logic. [Learn more about PayLinks](/v3-beta/docs/features/paylinks) Full control over the checkout experience. Best for SaaS, e-commerce, and digital sellers who need custom checkout flows, webhook-driven access control, or tight backend integration. 1. Go to **Settings → API Keys** and generate your API key 2. Send it in the `X-Suby-Api-Key` header on every request 3. Call the [Checkout Sessions endpoint](/v3-beta/api-reference/overview) to create a session, then redirect the payer to the `url` it returns ```bash theme={null} curl -X POST https://api.beta.suby.fi/v3/checkout/sessions \ -H "X-Suby-Api-Key: sk_live_xxx" \ -H "Content-Type: application/json" \ -d '{ "mode": "payment", "productId": "pro_xxx", "customer": { "email": "user@example.com" }, "successUrl": "https://yourapp.com/success", "cancelUrl": "https://yourapp.com/cancel" }' ``` Use `"mode": "subscription"` to open a subscription instead · a recurring product sold as `payment` is charged once and never renews. [Full API reference](/v3-beta/api-reference/overview) Best for communities and creators who sell access to a Discord server or specific roles. Suby grants and revokes roles automatically when a payment goes through, a subscription renews, or a customer cancels, no manual work required. [Full Discord integration guide](/v3-beta/docs/guides/discord/overview) Best for creators who sell access to a Telegram group or channel. Suby manages access automatically on payment, renewal, and cancellation, no bots to configure manually. [Full Telegram integration guide](/v3-beta/docs/guides/telegram/overview) ## Step 4: Set up payouts Before you can receive money, configure where you want to be paid. 1. Go to **Settings → Payouts** 2. Choose your payout method: bank account, Venmo, PayPal, or stablecoins 3. Enter your details and save Payout fees: +1% for bank and stablecoin payouts. Venmo and PayPal are charged at their standard rates. ## You're live Once your account review is complete, switch to live mode from **Settings → General** and start collecting payments. Endpoints, authentication, webhooks. Gate access to roles and channels automatically. Unlock groups and channels on payment. Reach us on WhatsApp, Telegram, Discord, or email, whatever works for you. # Refer businesses to Suby Source: https://docs.suby.fi/v3-beta/docs/introduction/refer Earn 30% commission on every business you bring to Suby. Know someone who could use Suby? Refer them and earn 30% of their revenue, for as long as they stay on the platform. ## How it works Open a ticket in our Discord and we will set you up with a personal referral link. Discordticketrefer [Open a ticket](https://discord.gg/2wpagPBbXQ) Send your link to founders, developers, or anyone running an internet business who needs a better way to handle payments. Every time your referral generates revenue on Suby, you earn 30% of it. No cap, no expiry. ## FAQ As long as the business you referred stays on Suby, you keep earning. There is no time limit on your commission. Anyone running an internet business, SaaS, e-commerce, paid communities, agencies, or freelancers. If they can use Suby, you can earn from them. Payouts follow Suby's standard payout methods: bank account, Venmo, PayPal, or stablecoins. Details are confirmed when you open your referral ticket. ## Ready to start referring? Get your referral link and start earning 30% commission. # What is Suby? Source: https://docs.suby.fi/v3-beta/docs/introduction/what-is-suby Payment infrastructure for internet businesses. Operate as Merchant of Record or PayFac, cards, stablecoins, subscriptions, and global compliance in one place. Suby is **payment infrastructure** built for modern internet businesses. Accept payments globally across every major method, get paid your way, and operate either as a **Merchant of Record** or as **PayFac**, depending on what fits your business. Dashboard 1 ## What is Suby? Suby provides the infrastructure that lets you sell globally without managing the operational complexity of cross-border payments, tax filings, subscription logic, or settlement flows. Cards. Bank accounts. Apple Pay. Google Pay. Klarna. Stablecoins. Multiple payout options. All routed through a single, fast orchestration layer. Suby operates in two modes, **Merchant of Record** and **PayFac**. Which one applies to your account is decided by Suby when your business is accepted onboarding, based on your business type, volume, and risk profile, not something you self-select. See [Review Process](/v3-beta/docs/merchants/account-review-process) for how that works. Suby becomes the legal seller. We calculate, collect, and remit VAT, GST, and sales taxes across 190+ countries on your behalf. You remain the seller of record. Suby processes the payment at a lower fee, and you handle your own tax compliance and dispute management. Cards, bank accounts, Apple Pay, Google Pay, Klarna, and stablecoins across multiple chains, all available out of the box, in either mode. Subscriptions, dunning, discount codes, customer notifications, and a unified revenue dashboard out of the box. ## Problems We Solve Selling globally means dealing with VAT, GST, and sales taxes across dozens of jurisdictions with different rates, thresholds, and filing requirements. Most founders either ignore it (risky), hire expensive accountants, or limit where they sell. On **MoR mode**, Suby becomes the legal seller. We calculate, collect, file, and remit taxes worldwide. You never touch a tax form. On **PayFac mode**, tax handling remains your own responsibility, in exchange for a lower transaction fee. Running an internet business requires more than processing payments. You need subscription management, discount codes, customer notifications, analytics, and integrations. Using separate tools for each creates complexity and ongoing maintenance overhead. Suby brings everything together: subscription lifecycle, discount codes, automated notifications, Discord and Telegram integrations, and a unified revenue dashboard in one place, regardless of which mode your account runs on. Most payment platforms only support cards, with slow fiat payouts. Stablecoin-native businesses have nowhere to go, and businesses that want optionality have to stitch together multiple providers. Suby accepts cards, bank payments, Apple Pay, Google Pay, Klarna, and stablecoins natively, all orchestrated through a single integration. On the payout side: bank accounts or stablecoins. No forced currency conversion, no delays, no extra providers to manage. ## Core Features Sell digital products, services, or access with a fast checkout via API or PayLinks. Recurring billing with automatic renewals, trials, dunning, and flexible plan management. On MoR mode, VAT, GST, and sales tax across 190+ countries are calculated, collected, and remitted automatically. On PayFac mode, this is handled by you. Automatically grant or revoke Discord roles when users subscribe, cancel, or renew. Connect payments to Telegram bots and unlock premium groups or channels instantly. Bank accounts or stablecoins across multiple chains. ## Quick Start [Sign up for Suby](https://dashboard.suby.fi/). Takes under 1 minute. Suby reviews your business and assigns your account to MoR or PayFac mode, see [Review Process](/v3-beta/docs/merchants/account-review-process). Set up a one-time product or a subscription plan from your dashboard. Choose your price, and configure access delivery. Generate a **PayLink** and share it instantly with no code required. Integrate via the API for a fully custom checkout flow. Or connect Discord and Telegram to gate access automatically the moment a payment goes through. [PayLinks](/v3-beta/docs/features/paylinks) · [API](/v3-beta/api-reference/overview) · [Discord](/v3-beta/docs/features/discord-integration) · [Telegram](/v3-beta/docs/features/telegram-integration) ## Integration Options Create a payment link from your dashboard and share it anywhere. No code needed. Start in minutes. Full programmatic control over products, customers, subscriptions, and payouts. Gate access to roles, channels, and servers automatically when a payment goes through. Unlock premium groups and channels instantly the moment a subscriber pays. ## Suby vs. the Alternatives ### Merchant of Record / PayFac | | Suby | Stripe | Lemon Squeezy | Whop | | -------------------------------------------------- | ---- | -------------- | ------------- | ---- | | Can act as Merchant of Record | ✅ | ❌ | ✅ | ✅ | | Can act as PayFac (lower fee, you keep compliance) | ✅ | ✅ (by default) | ❌ | ❌ | | Global tax compliance (VAT, GST), MoR mode | ✅ | ❌ | ✅ | ✅ | | Tax filing and remittance included, MoR mode | ✅ | ❌ | ✅ | ✅ | ### Pay-in Methods | | Suby | Stripe | Lemon Squeezy | Whop | | -------------------------------------- | ---- | --------- | ------------- | ------- | | Cards (Visa, Mastercard) | ✅ | ✅ | ✅ | ✅ | | Apple Pay / Google Pay | ✅ | ✅ | ✅ | ✅ | | Klarna | ✅ | Partial | ❌ | Partial | | Bank payments | ✅ | ✅ | ❌ | ✅ | | Stablecoins multichain (USDC, USDT...) | ✅ | Partial\* | ❌ | Partial | \*Stripe supports USDC stablecoin pay-in via Bridge, limited rollout. ### Payout Methods | | Suby | Stripe | Lemon Squeezy | Whop | | ---------------------- | ---- | ------- | ------------- | ------- | | Bank account | ✅ | ✅ | ✅ | ✅ | | Stablecoins multichain | ✅ | Partial | ❌ | Partial | ### Developer Experience | | Suby | Stripe | Lemon Squeezy | Whop | | ----------------------- | ---- | ------ | ------------- | ------- | | Custom checkout via API | ✅ | ✅ | Partial | ❌ | | Webhooks | ✅ | ✅ | ✅ | ✅ | | Discord integration | ✅ | ❌ | ❌ | Partial | | Telegram integration | ✅ | ❌ | ❌ | Partial | ### Fees | | Suby | Stripe | Lemon Squeezy | Whop | | ---------------------------- | ----------------- | ------------- | ------------- | ------------- | | Transaction fee, MoR mode | **4% + \$0.40** | n/a | 5% + \$0.50 | 2.7% + \$0.30 | | Transaction fee, PayFac mode | **2.9% + \$0.30** | 2.9% + \$0.30 | n/a | n/a | | International surcharge | · | +1.5% | +1.5% | +1.5% | | Tax compliance included | MoR mode only | ❌ | ✅ | ✅ | **Stripe** is a payment processor, comparable to Suby's PayFac mode. You remain responsible for tax compliance, VAT registration, and global filings, unless you opt into Suby's MoR mode instead. **Lemon Squeezy** is a MoR but cards-only for pay-in, no native stablecoin support, and no API-first checkout for custom integrations. Acquired by Stripe in 2024, roadmap unclear. **Whop** is a marketplace platform, not pure infrastructure. Your product lives inside Whop's ecosystem. Suby is infrastructure you embed directly into your own product with full API access and no platform dependency. ## Transparent Pricing **4% + \$0.40** per transaction on MoR mode, or **2.9% + \$0.30** on PayFac mode. Which mode applies to your account is assigned by Suby when your business is accepted. You only pay when you generate revenue. No monthly fees. No setup costs. Additional payout fees, the same regardless of mode: * Bank account (USD/EUR): \$0.50 per payout * Crypto wallet (USDC/EURC): 0.5% + \$1 per payout Full breakdown on the [Pricing page](https://suby.fi/pricing). ## FAQ Most users get reviewed and start accepting payments within a short time of applying. Create an account, get your business reviewed, generate a PayLink or integrate the API, and start selling. Customers can pay with cards, bank transfers, Apple Pay, Google Pay, Klarna, or stablecoins: USDC, USDT, and more across multiple chains. Cash App support is coming soon. Suby assigns your account to MoR or PayFac mode when your business is accepted, based on your business type, sales volume, target markets, and risk profile. It isn't something you choose at signup, our team walks you through it. See [Review Process](/v3-beta/docs/merchants/account-review-process). Stripe is a payment processor, closest to Suby's PayFac mode: you remain responsible for tax compliance, filings, and global sales taxes. Suby can also act as your Merchant of Record, handling tax compliance, payments infrastructure, and global regulations for you, if your account is assigned to MoR mode. Whop is a marketplace for selling digital products and communities. Suby is payment infrastructure, able to act as Merchant of Record or PayFac, that lets you accept payments globally across every major method and integrate directly into Discord, Telegram, or your own product via API, with no marketplace dependency. A Merchant of Record is the legal entity responsible for a transaction. When your account is on Suby's MoR mode, Suby becomes the seller of record. We handle tax collection and remittance, fraud liability, regulatory compliance, and chargebacks so your business does not have to. If you're on PayFac mode instead, you remain the seller of record and keep that responsibility. [Learn more about MoR](/v3-beta/docs/merchants/what-is-a-merchant-of-record) or [PayFac](/v3-beta/docs/merchants/what-is-a-payfac). ## Ready to Start? Free signup. Get reviewed and start selling. Accept your first payment in minutes. Endpoints, authentication and webhooks. Get help from the team & other builders. # 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 10, 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 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 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 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.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 10, 2026 and supersede the previous version dated June 16, 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. # 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). # Suby Sandbox Source: https://docs.suby.fi/v3-beta/docs/sandbox/suby-sandbox Test payments end-to-end without touching real funds. The Suby Sandbox mirrors the full production experience. Create products, simulate card and crypto payments, and verify webhooks, all in a safe testing environment. Sandboxtest ## Create a test product You can create a product in sandbox mode using any of these methods: Create a product from the dashboard, no code required. Generate a PayLink and share it to test the full checkout flow. Programmatically create products, checkout sessions, and manage subscriptions via the Suby API. Use the sandbox base URL to test the full API lifecycle without side effects. ## Simulate a payment Once your product is created, open the generated checkout link to run a test payment: ```text theme={null} https://checkout.suby.fi/p/pro_nh5ts1yir4hva744jpvln1ek ``` Sandboxpaylink \ You can pay with a test card or with crypto on Base Sepolia testnet. Use these test card numbers at checkout to simulate different outcomes. Any future expiration date, any CVC, any billing address. | Card number | Result | | :-------------------- | :----------------- | | `4242 4242 4242 4242` | Success | | `4000 0000 0000 0002` | Declined | | `4000 0000 0000 9995` | Insufficient funds | Any other card number will be declined. The sandbox supports **USDC** and **ETH** on the **Base Sepolia** testnet. You'll need testnet tokens to simulate a payment. ### Get testnet tokens | Token | Faucet | | :------- | :------------------------------------------------------------------------------- | | **USDC** | [faucet.circle.com](https://faucet.circle.com/) | | **ETH** | [alchemy.com/faucets/base-sepolia](https://www.alchemy.com/faucets/base-sepolia) | ### Pay at checkout Two options are available at the checkout page: * **WalletConnect** · connect your wallet (MetaMask, Rainbow, etc.) and approve the transaction on Base Sepolia. * **Direct deposit** · send tokens directly to the payment address displayed at checkout. Make sure your wallet is connected to the **Base Sepolia** network before initiating a payment. ## Verify the payment After completing a test payment, head to your [dashboard](https://dashboard.suby.fi/) to check the transaction status, inspect webhook deliveries, and confirm that your integration works as expected. You can also listen for sandbox webhooks to test your backend logic. Webhook events in sandbox mode are identical to production. Endpoints, authentication, and webhooks. Generate and share checkout links. # 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`, `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. **`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. `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. **`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.canceled` | Canceled · now, or at the period boundary. | | `subscription.expired` | Ended. Access removed. | **A plan change emits no event of its own.** `POST /v3/subscriptions/{id}/change-plan` answers `202` and the swap lands later · on the upgrade charge completing, or at the next renewal for a period-end downgrade. Read `GET /v3/subscriptions/{id}`: while the change is queued it comes back under `scheduledChange`, and once applied that field is `null` and `productId` names the new plan. A period-end downgrade also announces itself as the `subscription.renewed` of the cycle that bills it. Suby drives renewals · you never call the API for cycle N+1. * **Card / wallets** · off-session smart retry, on a schedule sized to the plan's cadence so a dunning chain always finishes inside one billing period: **weekly and daily plans get 2 attempts** (done within 48h and 6h), **monthly and yearly plans get 4** (done within 7 days). 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** · a per-cycle email; the customer re-deposits and the subscription rolls forward. ### 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. # 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. # 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. # Use with AI Source: https://docs.suby.fi/v3-beta/docs/introduction/AI Integrate your product into your app in one click with your favorite AI builder. ## One-click integration Launch your favorite AI builder with the full Suby integration prompt already written. It scaffolds your database, API calls, webhook handler, and UI, so all you have to do is paste your API keys. Spin up a full Supabase + webhooks integration in one click. Open Claude with the full integration prompt pre-loaded. Open ChatGPT with the full integration prompt pre-loaded. After your AI finishes, add `[PRODUCT]_API_KEY` and `[PRODUCT]_WEBHOOK_SECRET` as secrets, then paste the webhook URL it gives you into **Suby Dashboard → Settings → Webhooks**. *** ## Just load the docs Want to ask questions instead of building? Open a chat with the full Suby documentation loaded as context. Load the full Suby docs into a Claude conversation. Load the full Suby docs into a ChatGPT conversation. *** ## Plain text If your tool accepts a URL or raw text, paste one of these directly into the context window. | Format | URL | Best for | | --------- | ------------------------------------ | ------------------------------ | | Summary | `https://docs.suby.fi/llms.txt` | Quick context, token-efficient | | Full docs | `https://docs.suby.fi/llms-full.txt` | Deep integration work | *** ## After the AI finishes Grab them from your [Suby dashboard](https://dashboard.suby.fi/dashboard/settings) and save them as: * `[PRODUCT]_API_KEY` * `[PRODUCT]_WEBHOOK_SECRET` Copy the webhook URL your AI generated and paste it into **Suby Dashboard → Settings → Webhooks**. Use Suby's test credentials to run a full end-to-end flow, verify the webhook fires, and confirm everything updates correctly in your database. Swap test credentials for production credentials and you're ready to ship. *** ## What the AI will know Once loaded, your assistant has full context on: Authentication, core resources, and all available operations. All events, payload structure, and signature verification. The main capabilities of Suby and how to use them. SDKs, frameworks, and platform-specific adapters. Resources, relationships, and recommended schema. Rate limits, quotas, and billing details. For complex integrations, use `llms-full.txt` for maximum context. For quick Q\&A, the summary `llms.txt` is faster. # Account Reviews Source: https://docs.suby.fi/v3-beta/docs/introduction/account-reviews Learn how account reviews work on Suby, and how to make yours successful. As a **Merchant of Record**, Suby acts as the reseller of your digital goods and services. All accounts must pass a compliance review before going live. This involves verifying legitimacy, preventing fraud, and ensuring alignment with our acceptable use guidelines. ## Checklist Your product is ready for production. No fake reviews, inflated user counts, or misleading testimonials on your website. Both pages must be publicly accessible on your website. We can understand what you sell from your landing page without guessing. Pricing must be visible and accessible to users before checkout. A reachable, branded email (e.g. `support@yourproduct.com`) not a generic Gmail address. Your product name doesn't infringe on existing trademarks or create consumer confusion. If your product generates AI images, video, or audio, NSFW filters are mandatory. *** ## How to submit Navigate to **Balance → Payout Account** in your Suby dashboard to start the review process. You'll need to provide: * Your full name and/or business entity name * Your store or product name * The URL of your product or landing page * A description of your business and how it operates * A description of the products you intend to sell through Suby * Your country of tax residency (or country of incorporation for business entities) *** ## The review process Reviews are typically completed within **24 hours**. During peak periods, up to 48 hours. Go to **Balance → Payout Account** and fill in your business and product details. Our team reviews your website, product, and submitted information. No action needed on your end. You'll receive an email confirmation. Payouts are now enabled. ### Common reasons for change requests These are the most frequent issues that delay or block account approval. | Issue | Fix | | ---------------------- | ------------------------------------------------------------------ | | Support email mismatch | Update it in **Settings → Business Details** to match your website | | Website not accessible | Make sure your site is live, public, and not returning errors | | Missing legal pages | Add a Privacy Policy and Terms of Service | | False information | Remove fake reviews, testimonials, or inflated metrics | | Product not ready | Use test mode until your product is live | *** ## Accepted products Suby supports digital goods and services that can be fulfilled online. Examples include: *** ## Prohibited & restricted products The following are **not permitted** on Suby. Attempting to sell these will result in suspension. This list is non-exhaustive. Our partners and providers may flag additional categories at any time. * Sexually-oriented or pornographic content of any kind * Face-swap, deepfake, and face-manipulation tools or services * IPTV services * Spyware or parental control apps * Products for which you do not hold proper IP rights * Marketplaces where you use Suby to resell other people's products * Dating sites * Counterfeit goods * Illegal or age-restricted products (drugs, alcohol, tobacco, vaping, puffs, nicotine pouches) * Regulated products (CBD, gambling, weapons, sweepstakes, lotteries, get-rich-quick schemes) * Regulated services (real estate, mortgage, lending, legal, banking, debt relief, warranties) * Pharmacies, pharmaceuticals, nutraceuticals, steroids, SARMs, peptides, hormones * Homework or essay mills * MLM, pyramid schemes, or IBO schemes * Cryptocurrencies, NFTs, tokens, ICOs, and mining-as-a-service * Forex, trading signals, copy-trading, prop firms, and high-yield investment programs * Crowdfunding, donation collection, fundraising platforms, and cash-advance services * Gift cards, prepaid cards, e-money, mobile top-ups, and money transfer services * Travel agencies, ticket resale, and timeshare offers * High-ticket coaching or mentoring promising guaranteed income or results * Dropshipping with delivery times exceeding 30 days * Auto-renewing subscriptions without clear and explicit consent (negative option billing) * Pre-orders or crowdfunded products that are not yet manufactured or in stock * Fake or fraudulent document generators (invoices, payslips, IDs, diplomas, proof of address) * Game cheats, hacks, bots, boosted accounts, and unauthorized in-game currency * Scraped data, email lists, lead databases, and personal data marketplaces * Sale or rental of social media, streaming, or online accounts * Sale of followers, likes, views, comments, or any artificial engagement * DRM circumvention, SIM unlocking, and jailbreak-as-a-service * Weapons, ammunition, weapon parts, and lethal tactical gear * Live animals and products derived from protected species (CITES, ivory, exotic wildlife) * Extremist, hateful, or violence-inciting content * Occult or esoteric services (psychic readings, spell casting, curse removal, love spells) * Kratom, kava, poppers, research chemicals, and unapproved nootropics * Contact lenses, medical devices, and direct-to-consumer diagnostic tests * Stresser, booter, or DDoS-for-hire services * 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 These categories require **strict due diligence**. Approval is not guaranteed · contact us before submitting. * Services of any kind (marketing, design, web development, consulting) * Job boards * Newsletter advertising * Social media advertising Reach out to [support@suby.fi](mailto:support@suby.fi) with a description of your product before you apply. *** ## Customer support requirements Visible on your website and in customer receipts. Must match your product domain. Users must be able to cancel directly from your product via the Suby API or Customer Portal. Respond to customer requests within 3 business days, or Suby may issue refunds on your behalf. *** ## Ongoing monitoring Suby continuously monitors all active accounts, not just at onboarding. Random audits are performed at any time and are typically completed within hours. We look at: * Product description and accuracy * Pricing and payment methods * Customer support and contact information * Website and landing page * Risk scores across historical transactions * Refund and chargeback ratios If we detect suspicious activity, your account may be placed under review without prior notice. Maintaining compliance at all times, not just during the initial review, is your responsibility as a merchant. # Quickstart Source: https://docs.suby.fi/v3-beta/docs/introduction/quickstart Accept your first payment in under 5 minutes. This guide walks you through enabling a payment method, creating a product, and collecting your first payment. ## Before you begin Make sure you have a Suby account. If not, [sign up here](https://dashboard.suby.fi/). New accounts go through a quick review before going live. [Learn more about the review process](/v3-beta/docs/merchants/account-review-process). ## Step 1: Enable a payment method Suby supports two payment methods. You can enable one or both. Visa, Mastercard, Amex, and all major cards. Higher conversion rates, automatic payouts, supports one-time payments and subscriptions. Reviews in 24h: [Apply for card payments](https://dashboard.suby.fi/) USDC, USDT, ETH, SOL, and BNB. Go live in minutes, accept worldwide, non-custodial, funds go directly to your wallet. Active by default: [Enable stablecoin payments](https://dashboard.suby.fi/) Onboarding 2 ## Step 2: Create a product Everything is configured in one place. From your [dashboard](https://dashboard.suby.fi/), click **Create product** and set up: * **Name**: what you're selling (e.g. "Pro Plan", "Premium Community", "Design Templates") * **Billing type**: one-time or recurring (monthly / yearly) * **Price**: in fiat (USD, EUR...) * **Integration**: how customers get access after paying (PayLink, API, Discord, or Telegram) You can create multiple products with different billing types, prices, and integrations, for example a monthly plan and a yearly plan. ## Step 3: Choose your integration The fastest way to start and the best option for testing or accepting payments without writing any code. Generate a checkout link and share it anywhere: your website, a Discord message, an email, a bio link. 1. From your product page, click **Generate PayLink** 2. Copy the link 3. Share it: your customers can pay immediately PayLinks can be combined with the API for more complex flows: use PayLinks for quick sales and the API for subscription management or custom logic. [Learn more about PayLinks](/v3-beta/docs/features/paylinks) Full control over the checkout experience. Best for SaaS, e-commerce, and digital sellers who need custom checkout flows, webhook-driven access control, or tight backend integration. 1. Go to **Settings → API Keys** and generate your API key 2. Send it in the `X-Suby-Api-Key` header on every request 3. Call the [Checkout Sessions endpoint](/v3-beta/api-reference/overview) to create a session, then redirect the payer to the `url` it returns ```bash theme={null} curl -X POST https://api.beta.suby.fi/v3/checkout/sessions \ -H "X-Suby-Api-Key: sk_live_xxx" \ -H "Content-Type: application/json" \ -d '{ "mode": "payment", "productId": "pro_xxx", "customer": { "email": "user@example.com" }, "successUrl": "https://yourapp.com/success", "cancelUrl": "https://yourapp.com/cancel" }' ``` Use `"mode": "subscription"` to open a subscription instead · a recurring product sold as `payment` is charged once and never renews. [Full API reference](/v3-beta/api-reference/overview) Best for communities and creators who sell access to a Discord server or specific roles. Suby grants and revokes roles automatically when a payment goes through, a subscription renews, or a customer cancels, no manual work required. [Full Discord integration guide](/v3-beta/docs/guides/discord/overview) Best for creators who sell access to a Telegram group or channel. Suby manages access automatically on payment, renewal, and cancellation, no bots to configure manually. [Full Telegram integration guide](/v3-beta/docs/guides/telegram/overview) ## Step 4: Set up payouts Before you can receive money, configure where you want to be paid. 1. Go to **Settings → Payouts** 2. Choose your payout method: bank account, Venmo, PayPal, or stablecoins 3. Enter your details and save Payout fees: +1% for bank and stablecoin payouts. Venmo and PayPal are charged at their standard rates. ## You're live Once your account review is complete, switch to live mode from **Settings → General** and start collecting payments. Endpoints, authentication, webhooks. Gate access to roles and channels automatically. Unlock groups and channels on payment. Reach us on WhatsApp, Telegram, Discord, or email, whatever works for you. # Refer businesses to Suby Source: https://docs.suby.fi/v3-beta/docs/introduction/refer Earn 30% commission on every business you bring to Suby. Know someone who could use Suby? Refer them and earn 30% of their revenue, for as long as they stay on the platform. ## How it works Open a ticket in our Discord and we will set you up with a personal referral link. Discordticketrefer [Open a ticket](https://discord.gg/2wpagPBbXQ) Send your link to founders, developers, or anyone running an internet business who needs a better way to handle payments. Every time your referral generates revenue on Suby, you earn 30% of it. No cap, no expiry. ## FAQ As long as the business you referred stays on Suby, you keep earning. There is no time limit on your commission. Anyone running an internet business, SaaS, e-commerce, paid communities, agencies, or freelancers. If they can use Suby, you can earn from them. Payouts follow Suby's standard payout methods: bank account, Venmo, PayPal, or stablecoins. Details are confirmed when you open your referral ticket. ## Ready to start referring? Get your referral link and start earning 30% commission. # What is Suby? Source: https://docs.suby.fi/v3-beta/docs/introduction/what-is-suby Payment infrastructure for internet businesses. Operate as Merchant of Record or PayFac, cards, stablecoins, subscriptions, and global compliance in one place. Suby is **payment infrastructure** built for modern internet businesses. Accept payments globally across every major method, get paid your way, and operate either as a **Merchant of Record** or as **PayFac**, depending on what fits your business. Dashboard 1 ## What is Suby? Suby provides the infrastructure that lets you sell globally without managing the operational complexity of cross-border payments, tax filings, subscription logic, or settlement flows. Cards. Bank accounts. Apple Pay. Google Pay. Klarna. Stablecoins. Multiple payout options. All routed through a single, fast orchestration layer. Suby operates in two modes, **Merchant of Record** and **PayFac**. Which one applies to your account is decided by Suby when your business is accepted onboarding, based on your business type, volume, and risk profile, not something you self-select. See [Review Process](/v3-beta/docs/merchants/account-review-process) for how that works. Suby becomes the legal seller. We calculate, collect, and remit VAT, GST, and sales taxes across 190+ countries on your behalf. You remain the seller of record. Suby processes the payment at a lower fee, and you handle your own tax compliance and dispute management. Cards, bank accounts, Apple Pay, Google Pay, Klarna, and stablecoins across multiple chains, all available out of the box, in either mode. Subscriptions, dunning, discount codes, customer notifications, and a unified revenue dashboard out of the box. ## Problems We Solve Selling globally means dealing with VAT, GST, and sales taxes across dozens of jurisdictions with different rates, thresholds, and filing requirements. Most founders either ignore it (risky), hire expensive accountants, or limit where they sell. On **MoR mode**, Suby becomes the legal seller. We calculate, collect, file, and remit taxes worldwide. You never touch a tax form. On **PayFac mode**, tax handling remains your own responsibility, in exchange for a lower transaction fee. Running an internet business requires more than processing payments. You need subscription management, discount codes, customer notifications, analytics, and integrations. Using separate tools for each creates complexity and ongoing maintenance overhead. Suby brings everything together: subscription lifecycle, discount codes, automated notifications, Discord and Telegram integrations, and a unified revenue dashboard in one place, regardless of which mode your account runs on. Most payment platforms only support cards, with slow fiat payouts. Stablecoin-native businesses have nowhere to go, and businesses that want optionality have to stitch together multiple providers. Suby accepts cards, bank payments, Apple Pay, Google Pay, Klarna, and stablecoins natively, all orchestrated through a single integration. On the payout side: bank accounts or stablecoins. No forced currency conversion, no delays, no extra providers to manage. ## Core Features Sell digital products, services, or access with a fast checkout via API or PayLinks. Recurring billing with automatic renewals, trials, dunning, and flexible plan management. On MoR mode, VAT, GST, and sales tax across 190+ countries are calculated, collected, and remitted automatically. On PayFac mode, this is handled by you. Automatically grant or revoke Discord roles when users subscribe, cancel, or renew. Connect payments to Telegram bots and unlock premium groups or channels instantly. Bank accounts or stablecoins across multiple chains. ## Quick Start [Sign up for Suby](https://dashboard.suby.fi/). Takes under 1 minute. Suby reviews your business and assigns your account to MoR or PayFac mode, see [Review Process](/v3-beta/docs/merchants/account-review-process). Set up a one-time product or a subscription plan from your dashboard. Choose your price, and configure access delivery. Generate a **PayLink** and share it instantly with no code required. Integrate via the API for a fully custom checkout flow. Or connect Discord and Telegram to gate access automatically the moment a payment goes through. [PayLinks](/v3-beta/docs/features/paylinks) · [API](/v3-beta/api-reference/overview) · [Discord](/v3-beta/docs/features/discord-integration) · [Telegram](/v3-beta/docs/features/telegram-integration) ## Integration Options Create a payment link from your dashboard and share it anywhere. No code needed. Start in minutes. Full programmatic control over products, customers, subscriptions, and payouts. Gate access to roles, channels, and servers automatically when a payment goes through. Unlock premium groups and channels instantly the moment a subscriber pays. ## Suby vs. the Alternatives ### Merchant of Record / PayFac | | Suby | Stripe | Lemon Squeezy | Whop | | -------------------------------------------------- | ---- | -------------- | ------------- | ---- | | Can act as Merchant of Record | ✅ | ❌ | ✅ | ✅ | | Can act as PayFac (lower fee, you keep compliance) | ✅ | ✅ (by default) | ❌ | ❌ | | Global tax compliance (VAT, GST), MoR mode | ✅ | ❌ | ✅ | ✅ | | Tax filing and remittance included, MoR mode | ✅ | ❌ | ✅ | ✅ | ### Pay-in Methods | | Suby | Stripe | Lemon Squeezy | Whop | | -------------------------------------- | ---- | --------- | ------------- | ------- | | Cards (Visa, Mastercard) | ✅ | ✅ | ✅ | ✅ | | Apple Pay / Google Pay | ✅ | ✅ | ✅ | ✅ | | Klarna | ✅ | Partial | ❌ | Partial | | Bank payments | ✅ | ✅ | ❌ | ✅ | | Stablecoins multichain (USDC, USDT...) | ✅ | Partial\* | ❌ | Partial | \*Stripe supports USDC stablecoin pay-in via Bridge, limited rollout. ### Payout Methods | | Suby | Stripe | Lemon Squeezy | Whop | | ---------------------- | ---- | ------- | ------------- | ------- | | Bank account | ✅ | ✅ | ✅ | ✅ | | Stablecoins multichain | ✅ | Partial | ❌ | Partial | ### Developer Experience | | Suby | Stripe | Lemon Squeezy | Whop | | ----------------------- | ---- | ------ | ------------- | ------- | | Custom checkout via API | ✅ | ✅ | Partial | ❌ | | Webhooks | ✅ | ✅ | ✅ | ✅ | | Discord integration | ✅ | ❌ | ❌ | Partial | | Telegram integration | ✅ | ❌ | ❌ | Partial | ### Fees | | Suby | Stripe | Lemon Squeezy | Whop | | ---------------------------- | ----------------- | ------------- | ------------- | ------------- | | Transaction fee, MoR mode | **4% + \$0.40** | n/a | 5% + \$0.50 | 2.7% + \$0.30 | | Transaction fee, PayFac mode | **2.9% + \$0.30** | 2.9% + \$0.30 | n/a | n/a | | International surcharge | · | +1.5% | +1.5% | +1.5% | | Tax compliance included | MoR mode only | ❌ | ✅ | ✅ | **Stripe** is a payment processor, comparable to Suby's PayFac mode. You remain responsible for tax compliance, VAT registration, and global filings, unless you opt into Suby's MoR mode instead. **Lemon Squeezy** is a MoR but cards-only for pay-in, no native stablecoin support, and no API-first checkout for custom integrations. Acquired by Stripe in 2024, roadmap unclear. **Whop** is a marketplace platform, not pure infrastructure. Your product lives inside Whop's ecosystem. Suby is infrastructure you embed directly into your own product with full API access and no platform dependency. ## Transparent Pricing **4% + \$0.40** per transaction on MoR mode, or **2.9% + \$0.30** on PayFac mode. Which mode applies to your account is assigned by Suby when your business is accepted. You only pay when you generate revenue. No monthly fees. No setup costs. Additional payout fees, the same regardless of mode: * Bank account (USD/EUR): \$0.50 per payout * Crypto wallet (USDC/EURC): 0.5% + \$1 per payout Full breakdown on the [Pricing page](https://suby.fi/pricing). ## FAQ Most users get reviewed and start accepting payments within a short time of applying. Create an account, get your business reviewed, generate a PayLink or integrate the API, and start selling. Customers can pay with cards, bank transfers, Apple Pay, Google Pay, Klarna, or stablecoins: USDC, USDT, and more across multiple chains. Cash App support is coming soon. Suby assigns your account to MoR or PayFac mode when your business is accepted, based on your business type, sales volume, target markets, and risk profile. It isn't something you choose at signup, our team walks you through it. See [Review Process](/v3-beta/docs/merchants/account-review-process). Stripe is a payment processor, closest to Suby's PayFac mode: you remain responsible for tax compliance, filings, and global sales taxes. Suby can also act as your Merchant of Record, handling tax compliance, payments infrastructure, and global regulations for you, if your account is assigned to MoR mode. Whop is a marketplace for selling digital products and communities. Suby is payment infrastructure, able to act as Merchant of Record or PayFac, that lets you accept payments globally across every major method and integrate directly into Discord, Telegram, or your own product via API, with no marketplace dependency. A Merchant of Record is the legal entity responsible for a transaction. When your account is on Suby's MoR mode, Suby becomes the seller of record. We handle tax collection and remittance, fraud liability, regulatory compliance, and chargebacks so your business does not have to. If you're on PayFac mode instead, you remain the seller of record and keep that responsibility. [Learn more about MoR](/v3-beta/docs/merchants/what-is-a-merchant-of-record) or [PayFac](/v3-beta/docs/merchants/what-is-a-payfac). ## Ready to Start? Free signup. Get reviewed and start selling. Accept your first payment in minutes. Endpoints, authentication and webhooks. Get help from the team & other builders. # Suby Sandbox Source: https://docs.suby.fi/v3-beta/docs/sandbox/suby-sandbox Test payments end-to-end without touching real funds. The Suby Sandbox mirrors the full production experience. Create products, simulate card and crypto payments, and verify webhooks, all in a safe testing environment. Sandboxtest ## Create a test product You can create a product in sandbox mode using any of these methods: Create a product from the dashboard, no code required. Generate a PayLink and share it to test the full checkout flow. Programmatically create products, checkout sessions, and manage subscriptions via the Suby API. Use the sandbox base URL to test the full API lifecycle without side effects. ## Simulate a payment Once your product is created, open the generated checkout link to run a test payment: ```text theme={null} https://checkout.suby.fi/p/pro_nh5ts1yir4hva744jpvln1ek ``` Sandboxpaylink \ You can pay with a test card or with crypto on Base Sepolia testnet. Use these test card numbers at checkout to simulate different outcomes. Any future expiration date, any CVC, any billing address. | Card number | Result | | :-------------------- | :----------------- | | `4242 4242 4242 4242` | Success | | `4000 0000 0000 0002` | Declined | | `4000 0000 0000 9995` | Insufficient funds | Any other card number will be declined. The sandbox supports **USDC** and **ETH** on the **Base Sepolia** testnet. You'll need testnet tokens to simulate a payment. ### Get testnet tokens | Token | Faucet | | :------- | :------------------------------------------------------------------------------- | | **USDC** | [faucet.circle.com](https://faucet.circle.com/) | | **ETH** | [alchemy.com/faucets/base-sepolia](https://www.alchemy.com/faucets/base-sepolia) | ### Pay at checkout Two options are available at the checkout page: * **WalletConnect** · connect your wallet (MetaMask, Rainbow, etc.) and approve the transaction on Base Sepolia. * **Direct deposit** · send tokens directly to the payment address displayed at checkout. Make sure your wallet is connected to the **Base Sepolia** network before initiating a payment. ## Verify the payment After completing a test payment, head to your [dashboard](https://dashboard.suby.fi/) to check the transaction status, inspect webhook deliveries, and confirm that your integration works as expected. You can also listen for sandbox webhooks to test your backend logic. Webhook events in sandbox mode are identical to production. Endpoints, authentication, and webhooks. Generate and share checkout links.