One-line takeaway: In Turkey, using crypto in the payment leg (i.e., inside the actual checkout, authorization, clearing, or settlement steps) is off-limits. If a merchant wants crypto exposure, keep it outside the regulated payment service and settle fiat-only.
Why this keeps coming up
A high-growth merchant says: “We want customers to pay with BTC/USDT right in checkout, and we want you to settle us in crypto.” It sounds modern. It also puts your license, sponsor bank relations, and reputational standing on the line.
For payment institutions (PIs), e-money institutions (EMIs), acquirers and PayFacs, the rule of thumb is simple: payments are fiat. The minute crypto touches the payment leg, you’ve created a compliance problem you don’t need—especially while fundraising, pursuing partnerships, or going through an exit.
The quick legal frame
- Turkey’s central bank prohibits using crypto as a means of payment and bars PIs/EMIs from directly or indirectly facilitating crypto within payment services or e-money issuance.
- AML obligations still apply to crypto-asset service providers, but strong AML does not convert a prohibited payment flow into a permitted one.
- Translation: even with full KYC/monitoring, using crypto in the payment leg is still a no.
What counts as the “payment leg”?
Think of the payment leg as the regulated pipe: checkout → authorization → capture/clearing → settlement → refunds/chargebacks. If crypto appears anywhere in that pipe (customer pays in crypto; you settle in crypto; you route funds to or from a crypto platform as part of payment), you’ve crossed the line.
Allowed: Activities the merchant does after you’ve finished a normal, fiat settlement, handled by the merchant (or its separate affiliate) with a VASP, outside your payment service.
Why investors care
- License risk: One rogue integration can spook banks, card schemes, and regulators.
- Operational chaos: Refunds, disputes, and reconciliations don’t map cleanly when a transaction is half-card, half-crypto.
- Narrative risk: The headline “PSP enables crypto payments despite ban” writes itself and follows you into diligence.
- Valuation drag: Buyers price uncertainty. Clean pipes get better multiples.
A real-world scenario (and how it unravels)
Merchant ask: “Add a ‘Pay with USDT’ button; convert card funds into USDT before settlement; send USDT to our wallet.”
Why it breaks:
- Conversion inside the payment flow = crypto in the payment leg.
- Routing funds to a crypto platform as part of your service = you’re intermediating a prohibited use-case.
- Settlement in crypto = also inside the regulated leg.
Downstream fallout: Refunds/chargebacks don’t match blockchain transfers; your scheme reporting becomes unreliable; your AML and ops teams are trapped in manual work.
The compliant design (that still gives the merchant what they want)
Option A — The “hard wall” pattern (recommended)
- Customer pays in fiat through your normal rails (card/FAST/transfer).
- You settle in fiat to the merchant, on your usual schedule.
- After settlement, the merchant (not you) buys or hedges crypto with its own VASP via its own contract and systems.
Why it works: You never touch crypto in your regulated service. Your system, contracts, and reconciliation stay clean.
Option B — Rewards outside the flow
- Keep purchase and settlement fiat-only.
- If the merchant wants crypto rewards or cashback, they handle it post-purchase, directly with a VASP. No instructions or funds routing from you.
Flow diagrams
- Diagram 1: Fiat-only payment leg
Lanes: Customer → PSP/Acquirer → Card/Bank rails → Settlement to Merchant (TRY).
Notes: Refunds flow back on the same fiat rails. - Diagram 2: Merchant-side crypto (off-flow)
After receiving fiat settlement, Merchant → VASP (own contract) → Crypto position or rewards wallet.
Notes: No PSP/EMI mediation; no references in your SoW; separate support lines.
Contract language you can paste (short and clear)
- No Crypto in Payment Leg
“The Parties acknowledge that crypto assets shall not be accepted, transferred, cleared, or settled within the payment or e-money services under this Agreement. Provider delivers payment and settlement strictly in fiat currency.” - No Intermediation to VASPs
“Provider will not route or intermediate funds to or from any crypto-asset service provider as part of the Services. Merchant shall not request such routing or intermediation.” - Merchant-side Crypto (Carve-Out)
“Merchant may, outside the Services and after fiat settlement, obtain crypto exposure through third parties under Merchant’s own agreements. Such activity imposes no obligations on Provider.” - Breach = Suspension
“Any breach of the foregoing entitles Provider to immediate suspension and termination for cause.”
Sales and product talk tracks (so the answer is “no” without saying “no”)
- “We’re licensed to process fiat payments. To protect both of us, crypto exposure has to live outside checkout and settlement.”
- “We can still support your marketing goals: settle you in fiat and you can run a separate, merchant-side crypto program with your VASP.”
- “Keeping using crypto in the payment leg out of the flow means faster approvals from banks/schemes and simpler refunds for your customers.”
Risk heat-map (how to triage requests)
| Merchant Request | Risk | Allowed if… | Owner |
|---|---|---|---|
| “Pay with BTC/USDT” button at checkout | Red | Not allowed | Decline |
| Settle us in crypto | Red | Not allowed | Decline |
| Convert card funds to crypto before settlement | Red | Not allowed | Decline |
| Crypto rewards after fiat settlement | Amber | Merchant handles fully off-flow, own VASP, no PSP mediation | Merchant |
| “Pay in fiat; we hedge later” | Green | Normal fiat leg; merchant hedges post-settlement | Merchant |
Evidence packet (what to collect when a merchant pushes)
- Flow charts of the proposed design, annotated where crypto would enter the payment pipe.
- Emails/slides where the merchant asks for crypto in checkout or settlement.
- Your alternate diagram showing fiat-only flow and a separate merchant-side crypto leg.
- Standard clause sheet (the four clauses above) ready for Legal to insert.
- Internal FAQ for sales and support.
Operational guardrails (so no one accidentally crosses the line)
- Keyword flags: Any deal notes containing “crypto, coin, token, stablecoin, BTC, USDT” trigger Legal/Compliance review.
- Marketing pre-check: No copy that implies “pay in crypto.” Use “merchant offers crypto rewards externally” instead.
- Refund sanity: Refunds must mirror the original fiat rails—no exceptions.
- Partner registry: List of VASPs the merchant may use, with a reminder they’re outside your service scope.
- Audit trail: Store the merchant’s request and your declined/alternative response for auditors and banks.
FAQs (for boards and lenders)
Can we allow crypto at checkout if we do perfect KYC?
No. Strong AML is good practice, but it doesn’t change the baseline: using crypto in the payment leg is prohibited.
What about settling the merchant in crypto after card capture?
If settlement is part of your payment service, it must be fiat-only. The merchant can buy or hedge crypto after your fiat settlement, outside your service.
Is trading or holding crypto illegal in Turkey?
No. But payments must not use crypto. Keep the lines clean and you stay both innovative and compliant.
TL;DR for founders and investors
The safe, scalable pattern in Turkey is: fiat in, fiat out. Keep checkout, authorizations, and settlement clean. If a merchant insists on “crypto,” move that desire outside the regulated payment function—after settlement, under their own contracts, systems, and risk. That way, using crypto in the payment leg never happens, you preserve banking relationships, and diligence remains boring (the way you want it).
Yanıt yok