Conceptvoorstel · haalbaarheid eerst

Internationaal shoppen.
Betalen in SRD.

Een mogelijke betaalbrug voor gebruikers in Suriname: een SRD-wallet, een browserextensie en een centrale betaalservice die een goedgekeurde betaalroute gebruikt voor online aankopen in het buitenland.

Belangrijk: dit is een concept en haalbaarheidsplan, geen live betaaldienst. Kaartuitgifte, financiering en regelgeving zijn nog te valideren.

↗ SRD BRUG
Beveiligde sessie
a
Online checkoutVoorbeeld: internationale webshop
TOTAAL IN JE WALLETVALUTA
SRD 1.938 indicatief
US$ 50,00 + voorbeeldkosten
Beschikbaar saldo•••
SRD 2.000,00
VoorbeeldsaldoWallet
✓ Eén wallet · meerdere betaalroutes
◎
Eén herkenbare gebruikerservaring

De gebruiker ziet de kosten in SRD en keurt de aankoop goed via de eigen wallet.

↗
De extensie als brug

De webshop hoeft niet direct met ons platform geïntegreerd te zijn als een geaccepteerde betaalkaart in de normale checkout werkt.

⌁
Eerst één werkende aankoop

Bewijs de volledige betaal- en bevestigingsketen voordat we een groot platform bouwen.

01 / Het probleem

De betaalmogelijkheid is vaak de ontbrekende schakel.

Het doel is niet om nóg een webshop te bouwen. Het doel is om gebruikers in Suriname te helpen online te kopen waar zij nu moeite hebben met internationale betaalmethoden.

“

De gebruiker moet kunnen blijven winkelen op de website die hij al kent — terwijl onze oplossing de betaalbrug vormt.

De kern van het concept
↯

Beperkte toegang tot internationale betaalproducten

Niet iedere Surinaamse gebruiker kan zonder meer een account openen bij een internationale betaaldienst. Stripe noemt Suriname bijvoorbeeld niet op de huidige lijst van ondersteunde landen voor standaard betalingen. Dit moet per product en aanbieder worden gecontroleerd.

$

Valuta en kosten zijn onduidelijk

Gebruikers willen vóór goedkeuring weten hoeveel SRD een aankoop kost, welke koers is gebruikt en welke servicekosten worden toegevoegd.

⤴

Een losse betaling is niet genoeg

Een betaling die buiten de webshop wordt gedaan, zorgt niet automatisch dat de webshop een bestelling als betaald markeert. De betaling moet via de eigen checkout of een door de verkoper goedgekeurde betaalroute lopen.

✓

Het gewenste resultaat

De bestelling blijft zichtbaar bij de merchant, de merchant bevestigt de betaling normaal en de gebruiker ziet de bijbehorende SRD-transactie in onze eigen app.

02 / De voorgestelde werking

Van SRD-wallet naar normale checkout.

De browserextensie start en begeleidt het proces. De backend beheert het geld en de transactie. Een geschikte uitgever en betaalinfrastructuur maken de kaartbetaling mogelijk.

01

Shoppen

De gebruiker logt zelf in op een webshop en kiest product(en) zoals gewoonlijk.

02

Detecteren

De extensie leest waar toegestaan de merchant, valuta en getoonde checkoutgegevens.

03

Goedkeuren

De backend toont het SRD-totaal, kosten en koers. De gebruiker bevestigt deze specifieke aankoop.

04

Betalen

Een goedgekeurde betaalkaart wordt via de normale checkout gebruikt. De merchant verwerkt de betaling via zijn eigen betaalstroom.

05

Controleren

De merchantorder en betaalstatus worden gekoppeld en met de uitgever vergeleken; daarna wordt de wallet bijgewerkt.

ⓘ
Cruciale voorwaarde
Dit werkt alleen wanneer een uitgever het kaartprogramma en deze use-case toestaat én de kaart door de merchant wordt geaccepteerd. Een order-ID op zichzelf is geen betaalbewijs. De extensie mag een merchant niet zelf vertellen dat een externe betaling heeft plaatsgevonden.
03 / Welke route gebruiken we?

Drie modellen, met een duidelijke voorkeur.

Kies hieronder een model om de voor- en nadelen te vergelijken. De eerste optie past het beste bij de gewenste ervaring, maar is afhankelijk van een goedgekeurde uitgever.

Voorkeursroute · afhankelijk van partner

De betaling loopt via de echte checkout

De gebruiker behoudt waar mogelijk de eigen webshopaccount. De extensie helpt de betaalkaart in de checkout te gebruiken, zodat de merchant zelf de betaling kan autoriseren en de bestelling kan registreren.

  • Geen directe integratie met elke webshop nodig als een standaardkaartbetaling wordt geaccepteerd.
  • De merchant behoudt zijn normale order- en bevestigingsproces.
  • Een geschikte uitgever, toegestane klantgroep en gefinancierde kaartregeling zijn harde voorwaarden.
Nog niet bewezen: er is geen bevestigde issuer gevonden die dit programma voor Surinaamse gebruikers accepteert. Dit is de eerste haalbaarheidspoort.
04 / Voorbeeldberekening

De gebruiker ziet eerst het SRD-totaal.

Een interactieve illustratie van hoe koers en servicekosten zichtbaar kunnen worden gemaakt. De ingevulde koers en kosten zijn voorbeelden, geen actueel tarief of aanbod.

Pas de voorbeeldbedragen aan

De berekening verandert direct mee, zodat je het prijsmodel kunt bespreken.

USD
SRD
SRD voor elke 1 USD
%
Exclusief eventuele vaste kosten of kosten van de issuer.
Dit is alleen een rekenvoorbeeld; wisselkoers en prijsmodel moeten later contractueel worden vastgesteld.
Geschat totaal voor de gebruiker
SRD 1.938,00

Bedrag in SRD vóór bevestiging van de definitieve checkout.

Bedrag omgerekendSRD 1.900,00
ServicekostenSRD 38,00
Valuta van merchantUSD 50,00

In productie moet de backend de quote berekenen, laten verlopen na een vastgestelde tijd en vóór betaling controleren of het definitieve merchanttotaal nog overeenkomt.

05 / Waarde en voordelen

Wat zou deze oplossing beter maken?

De echte waarde zit in gemak en toegang — op voorwaarde dat de betaling betrouwbaar werkt en de kosten eerlijk worden getoond.

₨

Één saldo in SRD

De gebruiker ziet een bekend saldo en hoeft niet bij elke aankoop zelf de omrekening en bijkomende kosten te berekenen.

Voorwaarde: transparante koers en kosten
↗

Meer keuze in webshops

Een standaardkaartbetaling kan websites bereikbaar maken zonder dat elke verkoper het nieuwe platform hoeft te integreren.

Voorwaarde: merchant accepteert de kaart
▤

Eén transactieoverzicht

De gebruiker kan aankopen, walletbewegingen, kosten, terugbetalingen en statussen op één plek volgen.

Voorwaarde: goede koppeling en reconciliatie
⌁

Meerdere betaalroutes

Op termijn kan de backend verschillende goedgekeurde betaalroutes kiezen op basis van beschikbaarheid, kosten en acceptatie.

Niet elke route is overal beschikbaar
♧

Minder betaalfrictie

Een herkenbare browserervaring kan de noodzaak verminderen om tijdens elke aankoop zelf nieuwe betaalrekeningen te regelen.

De extensie vervangt geen issuer
✓

Gebruiker houdt controle

Elke aankoop toont merchant, bedrag, valuta en kosten; de gebruiker bevestigt vóór de betaling.

Geen verborgen of automatische afschrijving
06 / Grenzen en risico's

Wat kan het project blokkeren?

Deze punten zijn geen details voor later. Ze bepalen of het concept juridisch, operationeel en commercieel haalbaar is.

▣
Hoog · blokkerend

Geen geschikte kaartuitgever

Een virtuele kaart vereist een issuer, processor en goedgekeurd programma. Publieke documentatie bewijst niet dat een specifieke aanbieder Surinaamse gebruikers voor dit model zal accepteren.

Aanpak: schriftelijke bevestiging vragen over doelgroep, regio, gebruik, financiering en risicoverdeling vóór ontwikkeling.
⚖
Hoog · blokkerend

Vergunningen en klantgelden

SRD aannemen, saldi beheren, valuta omzetten en internationale betalingen regelen kan onder financiële regels vallen. De precieze classificatie van dit model is nog niet vastgesteld.

Aanpak: juridisch advies in Suriname en duidelijke bespreking met CBvS en een bevoegde financiële partner.
↔
Hoog · technisch

Merchant accepteert de kaart niet

Webshops kunnen transacties weigeren door regio, kaarttype, frauderegels of verificatie-eisen. Geen enkele betaalroute werkt gegarandeerd op elke website.

Aanpak: beginnen met één merchant; acceptatiepercentage en foutredenen meten.
◷
Middel · financieel

Vertraagde of gesplitste afschrijving

De merchant kan eerst autoriseren en later afschrijven; verzendingen kunnen aparte charges opleveren. Het totaal kan veranderen.

Aanpak: reserveringen en limieten, voldoende buffer, statusmodel en reconciliatie per transactie.
⌁
Middel · security

Fraude en gevoelige betaaldata

Een browserextensie heeft beperkte toegang nodig. Wachtwoorden, sessiecookies en kaartbeveiligingscodes mogen niet naar de backend worden gekopieerd of onveilig worden bewaard.

Aanpak: minimale permissies, beveiligde issuer-flow, auditlogs, PCI-beoordeling en nooit CVV na autorisatie opslaan.
$
Middel · verdienmodel

Kosten en liquiditeit

Kaartuitgever, verwerking, FX, lokale stortingen, refunds, chargebacks en klantenservice kosten geld. Een lage marge kan snel verdwijnen.

Aanpak: alle kosten per geslaagde aankoop modelleren en een limiet- en reservebeleid bepalen vóór publieke lancering.
Stop/go-regel: als er geen bevoegde partner is die de kaart- en geldstroom schriftelijk accepteert, bouwen we geen live wallet en nemen we geen geld van het publiek aan. We kunnen wel een niet-financiële demo en provideronderzoek uitvoeren.
07 / Aanbieders en haalbaarheid

Wat de openbare informatie ons wel — en niet — vertelt.

Onderstaande informatie helpt bij het kiezen van gesprekspartners. Het is geen bevestiging dat een partij het volledige voorgestelde model zal ondersteunen.

1

Stripe: geen directe standaardaccount-route voor Suriname

Suriname staat niet op Stripe's huidige lijst voor standaard betalingsondersteuning. Een buitenlandse rechtspersoon is op zichzelf niet genoeg; Stripe beschrijft aanvullende eisen voor een onderneming en fysieke aanwezigheid in een ondersteund land. Ook betekent toegang tot Stripe Payments niet automatisch toegang tot Stripe Issuing of toestemming voor dit bedrijfsmodel.

Stripe — ondersteunde landen ↗ · Vereisten voor een account in een ander land ↗

2

Visa: vraag naar het kaartprogramma, niet alleen naar een API

Visa beschrijft dat een kaartprogramma doorgaans een bankrelatie, issuer processor en vaak een program manager nodig heeft. De sponsoringbank speelt een rol bij gelden, risico en lokale regelgeving. Dit is een logisch startpunt om potentiële partners te vinden, maar geen garantie op toelating in Suriname.

Visa — soorten programmapartners ↗

3

Adyen Issuing: huidige regio's zijn beperkt

De officiële documentatie noemt de Europese Economische Ruimte, het Verenigd Koninkrijk en de Verenigde Staten. Dat maakt het geen bevestigde rechtstreekse oplossing voor een programma voor inwoners van Suriname.

Adyen Issuing — ondersteunde regio's ↗

4

CBvS: lokale geldstromen vooraf laten beoordelen

De Centrale Bank van Suriname houdt toezicht op geldtransactiekantoren, waaronder wisselkantoren en geldovermakingskantoren. Haar FAQ vermeldt dat vreemde valuta wisselen met derden is voorbehouden aan bevoegde instellingen. Laat juridisch vaststellen welke regels op de voorgenomen wallet, omzetting en internationale betaling van toepassing zijn.

CBvS — geldtransactiekantoren ↗ · CBvS — FAQ wisselkantoren ↗

5

Lokale fundingprovider: apart te onderzoeken

Uni5Pay+, Mope en lokale bankpartners kunnen kandidaten zijn voor het lokale financieringsdeel. Dat een provider een QR-betaling, merchantbetaling of API ondersteunt, bewijst niet dat hij klant-wallets mag financieren of dat dit model binnen zijn contract valt. Vraag naar een expliciete zakelijke use-case, settlement en compliancevoorwaarden.

✓
Bewijsgrens
Waar publieke documentatie geen antwoord geeft op de exacte Surinaamse use-case, staat dit plan openlijk als “nog te verifiëren”. Geen van de genoemde aanbieders wordt voorgesteld als reeds akkoord.
08 / Uitvoeringsplan

Eerst bewijs. Daarna pas bouwen.

Een gefaseerde aanpak voorkomt dat er maanden worden besteed aan een wallet en extensie zonder werkende route om daadwerkelijk af te rekenen.

Haalbaarheidscheck

Benader issuer/program managers, bespreek SRD-funding, klanten uit Suriname, kaartgebruik, settlement, refunds en vereiste vergunningen. Leg antwoorden vast.

Oplevering: schriftelijke go/no-go

Eén echte aankoop

Kies één gewone webshop en voer met toestemming van de partner een kleine test uit. Controleer de merchantorder, kaartautorisatie, charge, refund en foutscenario's.

Oplevering: end-to-end bewijs

Veilige basis

Bouw daarna de double-entry wallet-ledger, reservations, koerssnapshot, betaalstatussen, idempotency, reconciliatie en een beperkte gebruikersinterface.

Oplevering: getest test-/sandboxsysteem

Extensie en gecontroleerde pilot

Ondersteun één bewezen merchant, voeg duidelijke goedkeuring en foutmeldingen toe, meet declines en kosten en breid pas uit wanneer de eerste route betrouwbaar is.

Oplevering: beperkte pilot
Niet in fase 1 doen: geen belofte “werkt op iedere website”, geen automatisch proberen van een tweede provider na een onzekere transactie, geen publieke stortingen zonder goedgekeurde geldstroom en geen opslag van merchantwachtwoorden of sessiecookies.
Aanbevolen besluit

Ga door met haalbaarheid — niet meteen met de volledige bouw.

Technisch is een wallet, extensie en betaalbackend maakbaar. De beslissende onzekerheden zijn een goedgekeurd kaartprogramma voor Surinaamse gebruikers, een toegestane SRD-funding- en settlementstructuur en de echte acceptatie bij de merchant.

✓Behouden: SRD-wallet, extensie, centrale betaalservice en één transactieoverzicht.
✓Eerst bewijzen: één kaartbetaling door de echte merchant-checkout.
!Voorwaarde: schriftelijke partner- en regelgevingsbevestiging vóór publiek geld wordt aangenomen.
×Niet doen: een losse externe betaling behandelen alsof een bestaande merchantorder daardoor betaald is.
09 / Veelgestelde vragen

De belangrijkste vragen, kort beantwoord.

Niet noodzakelijk als de aankoop via een betaalkaart loopt die de webshop al accepteert. De merchant verwerkt dan zijn normale checkout. Voor specifieke providers, uitzonderlijke checkoutflows of eigen aankoopregelingen kan wel een aparte integratie of proces nodig zijn.
Nee. Een order-ID identificeert een bestelling, maar is geen betaalautorisatie. De merchant moet de betaling via de eigen checkout of een door hem goedgekeurde route ontvangen en bevestigen.
Dat is niet het uitgangspunt. Stripe Payments en Stripe Issuing zijn verschillende producten met verschillende voorwaarden. De huidige publieke land- en regio-informatie bevestigt geen Stripe Issuing-route voor Surinaamse gebruikers. Een issuerpartner moet dit expliciet goedkeuren.
Niet verantwoord voordat funding, kaartuitgifte, settlement, klantgelden en de toepasselijke regels zijn opgelost. De eerste demo kan zonder echt geld werken; live stortingen vereisen een goedgekeurde opzet.
De transactie blijft in een passende tussenstatus. De backend controleert issuer- en merchantgegevens voordat zij geld definitief boekt of opnieuw probeert. Elke poging krijgt een unieke interne referentie en idempotente verwerking om dubbele afschrijving te voorkomen.
10 / Bronnen

Officiële documentatie om zelf na te lezen.

De links hieronder zijn vooral officiële bronnen van betaalproviders, Visa, PCI SSC en de Centrale Bank van Suriname. Ze onderbouwen de genoemde algemene vereisten; partnergoedkeuring voor dit specifieke project is nog niet verkregen.

Onderzoeksdatum: 22 oktober 2026. Informatie van derden kan veranderen en moet opnieuw worden bevestigd voordat contracten worden gesloten of de dienst live gaat. Dit document is een concept- en haalbaarheidsvoorstel, geen juridisch, belastingtechnisch of financieel advies, geen betaalbelofte en geen goedkeuring van een provider. Het is bedoeld om de bespreking en due diligence te structureren.

Gekopieerd naar klembord