Payment Terms
Last updated: [TBD] · This is a working draft pending legal review.
These Payment Terms explain how payments are processed on the Coded platform: how money moves from a buyer to a merchant, who is responsible for what, what fees apply, and how failed payments, refunds, disputes, and chargebacks are handled. They apply to every merchant who accepts payments through Coded and form part of the agreement between you and Coded B.V.
In these terms, "Coded", "we", "us", and "our" mean Coded B.V., a private limited company (besloten vennootschap) registered in the Netherlands under Chamber of Commerce (KvK) number 42027097, VAT number NL869368795B01, with its registered office at De Taling 15, 2761 SL Zevenhuizen, The Netherlands. Coded B.V. is a wholly owned subsidiary of Coded Holding B.V. Coded operates internationally; the Netherlands is our place of registration and initial launch market, and our platform serves merchants worldwide.
"You", "merchant", and "your" mean the person or entity operating one or more projects on the platform under an Organization account and accepting payments through it. A "buyer" is the end customer who pays a merchant for goods or services through one of the merchant's projects. "Payment processors" means Stripe and Mollie, defined in Section 2. Capitalised terms not defined here have the meaning given in our Terms of Service.
1. How payments work on Coded
Coded provides the software that lets a merchant offer products through their projects, present a checkout to buyers, and receive funds. Coded itself does not hold, transmit, or take possession of buyer funds in the ordinary course of a transaction. When a buyer pays, the payment is processed by a regulated third-party payment processor and the funds are settled into the merchant's connected processor account, not to Coded.
In short:
- The merchant is the seller of the goods or services and is the party contracting with the buyer for the sale.
- The payment processor (Stripe or Mollie) authorises, captures, and settles the payment under its own agreement with the merchant.
- Coded provides the platform, the checkout experience, and the connection to the processors. Coded is the technology provider, not the payment institution and not the seller of the merchant's goods.
This allocation matters for the rest of these terms: because the merchant is the seller and the owner of the payment, the merchant is the party primarily responsible for fulfilment, refunds, and disputes relating to its sales.
2. Payment processors (Stripe and Mollie)
Coded integrates two licensed third-party payment processors:
- Stripe — operated by Stripe entities including Stripe Payments Europe, Ltd. and affiliated companies.
- Mollie — operated by Mollie B.V., a licensed payment institution in the Netherlands.
To accept payments, a merchant must onboard to one or both processors through the platform and accept that processor's own terms (for Stripe, the Stripe Connected Account Agreement and Stripe Services Agreement; for Mollie, the Mollie User Agreement, including their respective acceptable-use policies). Those agreements are between the merchant and the processor. By enabling payments on Coded, you agree to comply with the applicable processor terms, and you acknowledge that the processor — not Coded — is responsible for the regulated payment services it provides.
The processor may require identity verification, business information, and ongoing compliance checks (including anti-money-laundering and know-your-customer obligations). A processor may delay, suspend, hold, or reverse funds, or decline to onboard or continue serving a merchant, in accordance with its own terms and applicable law. Coded does not control these decisions and is not liable for a processor's exercise of its rights, though we will make reasonable efforts to surface relevant information to you.
2.1 Merchant of record
Unless expressly stated otherwise for a specific feature, the merchant is the merchant of record for sales made through its projects. This means the merchant is the seller responsible to the buyer for the goods or services, for applicable taxes on the sale, and for refunds, disputes, and chargebacks relating to those sales. Coded is not the merchant of record and is not a reseller of the merchant's products.
3. Supported payment methods
The payment methods available at checkout depend on the processor a merchant has enabled, the merchant's location and currency, the buyer's location, and the processor's own availability rules. Commonly supported methods include:
- Cards — major debit and credit card networks (for example Visa, Mastercard, American Express), subject to processor and network support.
- iDEAL — the Netherlands bank-transfer method.
- Bancontact — the Belgian card and mobile method.
- Other local and regional methods offered by Stripe or Mollie from time to time (for example SEPA Direct Debit, Apple Pay, Google Pay, and similar), where supported for the merchant's account and the buyer's market.
Available methods may change as processors add, remove, or modify them. Coded does not guarantee that any specific method will be available, continue to be available, or be available in any particular market. Some methods carry method-specific rules (for example, whether and how a payment can be refunded or recalled); those rules are set by the method and the processor.
4. Authorization, capture, and settlement
A typical card or method transaction moves through these stages:
- Authorization — at checkout, the processor asks the buyer's bank or the payment method to confirm that funds are available and the payment is permitted. Strong customer authentication (for example 3-D Secure) may be required depending on the method, the buyer's bank, and applicable law.
- Capture — the authorised amount is taken. For most transactions on the platform, capture happens at, or shortly after, the time of purchase. Some configurations may authorise first and capture later; where that applies, the processor's authorization windows and rules govern, and an uncaptured authorization may expire.
- Settlement and payout — the captured funds, less applicable processing costs (see Section 6), settle into the merchant's connected processor account and are paid out to the merchant's nominated bank account on the processor's payout schedule.
Coded relays these events between the checkout and the processor and reflects their status in the merchant's project dashboard. The authoritative record of any payment, authorization, capture, settlement, or payout is the record held by the relevant processor.
5. Currencies
The currencies a merchant can charge in, and the currency in which the merchant is paid out, are determined by the processor and the merchant's account configuration. Where a buyer pays in a currency different from the merchant's settlement currency, the processor applies currency conversion and may charge a conversion or cross-border fee under its own terms. Any such conversion costs are part of the pass-through processing cost described in Section 6 and are not set or retained by Coded. Displayed prices, taxes, and the final charged amount are the merchant's responsibility to configure correctly for the markets the merchant sells into.
6. Fees — 0% Coded platform fee
Coded charges a 0% platform fee on a merchant's payment transactions. We do not take a percentage of, or a per-transaction fee on, the payments your buyers make to you. There is no Coded commission, markup, or transaction fee layered onto your sales.
The only cost associated with processing a payment is the pass-through processing cost charged by the payment processor (Stripe or Mollie) under that processor's pricing. That cost is set by the processor, charged by the processor, and deducted from or invoiced against the merchant's settlement by the processor. Coded does not add to it and does not retain any part of it.
Separately from payment processing, Coded may charge subscription fees for publishing and operating projects on the platform. Those subscription fees are described in our Terms of Service and the applicable plan or pricing materials, are billed independently of buyer payments, and are unrelated to the 0% platform fee on transactions described above. Where Coded charges a subscription fee, applicable taxes (for example VAT) may be added in accordance with law.
7. Payouts and settlement to merchants
Payouts are made by the processor to the bank account the merchant configures with that processor. The payout schedule, minimum payout thresholds, currency, rolling reserves (if any), and any holds are governed by the processor's terms and the merchant's account status. Coded does not control payout timing and does not hold merchant funds between settlement and payout in the ordinary course.
A processor may delay or withhold a payout — for example for risk, verification, suspected fraud, excessive disputes, negative balances, or regulatory reasons — under its own terms. If a payout is delayed or withheld, the merchant should resolve it through the processor; Coded will make reasonable efforts to assist but cannot release funds it does not hold or control.
The merchant is responsible for keeping its processor account and bank details accurate and current. Incorrect or outdated details may cause failed or delayed payouts, for which Coded is not responsible.
8. Failed payments
A payment may fail or be declined for many reasons, including insufficient funds, an expired or blocked card, a failed authentication or fraud check, a network error, or a processor or bank decision. When a payment fails:
- the order or sale is not completed unless and until a successful payment is made;
- the buyer may be invited to retry with the same or a different method, subject to the merchant's checkout configuration and the processor's rules;
- no funds are captured for a failed authorization, and any temporary hold placed by the buyer's bank is released by the bank on its own timeline, not by Coded.
Coded is not responsible for a declined or failed payment or for any consequence of one (for example a missed sale). Repeated failed or fraudulent attempts may trigger processor or platform risk controls.
9. Refunds
Detailed refund handling is set out in our Refund Policy (see that document for the full process, timing, and merchant obligations). In summary, and as relevant to payments:
- The merchant, as merchant of record, is responsible for its own refund policy toward buyers and for honouring applicable mandatory consumer-protection rights in the buyer's jurisdiction.
- A refund is processed back through the original payment method via the processor. Refund timing depends on the method, the buyer's bank, and the processor.
- A refund returns the sale amount to the buyer. Processor pass-through processing costs on the original transaction may or may not be returned to the merchant depending on the processor's terms; Coded does not retain or refund processing costs because Coded does not charge them.
- Coded charges no fee on refunds, consistent with its 0% platform fee.
10. Disputes and chargebacks
A chargeback (or dispute) happens when a buyer asks their bank or card network to reverse a payment — for example because the buyer does not recognise the charge, claims the goods or services were not received or not as described, or alleges fraud. Some payment methods have equivalent reversal or recall mechanisms.
Because the merchant is the merchant of record and the owner of the payment:
- The merchant is liable for chargebacks, reversals, and disputes relating to its sales, including the disputed amount and any chargeback or dispute fee the processor charges under its terms.
- The merchant is responsible for responding to and contesting disputes through the processor's dispute process within the processor's and the card network's deadlines, including providing evidence (for example proof of delivery, communications, and the merchant's terms of sale).
- A disputed or reversed amount may be debited from the merchant's processor balance, deducted from future settlements, or recovered as a negative balance by the processor.
- Excessive disputes or chargeback rates may lead the processor to apply reserves, holds, increased monitoring, or termination of the merchant's processor account, under the processor's terms.
Coded does not adjudicate disputes between buyers and merchants and is not a party to the underlying sale. Coded will make reasonable efforts to surface dispute information in the merchant's dashboard, but the dispute itself is handled between the merchant, the buyer, and the processor. Coded charges no fee in connection with chargebacks.
11. Taxes
The merchant is responsible for determining, collecting, reporting, and remitting all taxes (including VAT, sales tax, and any other applicable taxes and duties) arising from its sales to buyers, and for configuring tax settings correctly for the markets it sells into. Coded does not act as a tax adviser or, unless expressly stated for a specific feature, as a tax collector or remitter for the merchant's sales. Where Coded charges its own subscription fees, Coded will handle taxes on those fees in accordance with law.
12. Fraud, risk, and prohibited use
The merchant must not use the platform or the payment processors for any prohibited or unlawful purpose, including any activity prohibited by the applicable processor's acceptable-use policy, money laundering, financing of illegal activity, or the sale of prohibited goods or services. Coded and the processors operate fraud-prevention and risk controls. Coded may suspend or restrict a merchant's access to payment features, and a processor may take action under its own terms, where there is suspected fraud, abuse, a breach of these terms or a processor's terms, or a legal or regulatory requirement.
13. Data and security
Payment data is handled by the processors, which are responsible for the regulated payment services and for the security standards applicable to card and payment data (including the payment-card-industry standards that apply to them). Coded is designed with a privacy-by-design posture and minimises the payment data it touches; sensitive card data is handled by the processors and is not stored by Coded. Platform data is hosted in the European Union (Frankfurt). How Coded processes personal data is described in our Privacy Policy. Nothing in this section claims any certification that Coded does not in fact hold.
14. Coded's role and limitation
Coded provides the platform and the connection to the processors "as is" to the extent permitted by law, and does not guarantee uninterrupted availability of payment features, any particular payment method, any settlement or payout timing, or any outcome of a payment, refund, or dispute. Coded is not the payment institution, is not the merchant of record for the merchant's sales, and is not a party to the contract between buyer and merchant. To the maximum extent permitted by applicable law, and without limiting any mandatory rights a user has under the law of their jurisdiction, Coded is not liable for the acts, omissions, decisions, fees, holds, or terms of the payment processors. Other limitations of liability are set out in our Terms of Service.
15. Changes to these terms
Coded may update these Payment Terms from time to time, for example to reflect changes in processors, methods, law, or platform features. Where a change is material, Coded will provide reasonable notice through the platform or by email. Continued use of payment features after a change takes effect constitutes acceptance of the updated terms, except where applicable law requires explicit consent.
16. Governing law and jurisdiction
These Payment Terms are governed by the laws of the Netherlands. The courts of Amsterdam, the Netherlands, have jurisdiction over any dispute arising out of or in connection with these terms. This does not deprive a user of the protection of mandatory provisions of the law of the user's place of residence or jurisdiction (including mandatory consumer-protection and data-protection law), where such provisions apply and cannot be derogated from by agreement.
Contact
Questions about these Payment Terms can be sent to:
- General and legal: legal@coded.eu
- Privacy: privacy@coded.eu
- Security: security@coded.co
Coded B.V., De Taling 15, 2761 SL Zevenhuizen, The Netherlands — KvK 42027097, VAT NL869368795B01. Effective date: 11 June 2026.
<!-- OPEN ITEMS FOR COUNSEL: - Confirm Coded B.V. is never merchant of record / never a regulated payment institution under PSD2 — verify the platform model genuinely keeps Coded outside payment-institution licensing, and that funds never flow through a Coded-controlled account. If any feature routes funds through Coded, this draft must change. - Confirm exact contracting parties and current legal names of Stripe entities (Stripe Payments Europe vs. others) and Mollie B.V., and whether merchants contract directly with the processor or via a platform/Connect arrangement that imposes obligations on Coded. - Verify the chargeback/refund-liability allocation (merchant bears disputes and fees) is consistent with the actual Stripe Connect / Mollie Connect configuration used, and with consumer law in target markets. - Confirm whether Coded ever acts as tax collector/remitter (e.g. for its own subscription fees, EU VAT MOSS / OSS, US sales tax nexus) and align Section 11 accordingly. - Confirm authorization/capture model in production (immediate capture vs. auth-then-capture) and update Section 4. - Verify the 0% platform fee statement holds across ALL transaction types and that no processor revenue-share flows back to Coded that could be construed as a transaction fee. - Confirm cross-references: Refund Policy, Terms of Service, Privacy Policy slugs/titles once finalised. - Confirm contact domain (coded.eu (legal/privacy) · coded.co (ops)) and whether dedicated legal/privacy/security inboxes exist. - Confirm consumer vs. B2B framing — Payment Terms here are merchant-facing; check whether a buyer-facing variant or disclosure is also required. -->