Anatomie van de oplichting met de 'Visa Direct Developer'-sandbox
De gehele oplichtingspraktijk berust op een bewuste en misleidende verwarring van twee wezenlijk verschillende zaken: de "Visa Direct Developer"-sandboxomgeving en het feitelijke productiebetalingsnetwerk van Visa Direct.
Fraudeurs maken misbruik van de term “Visa Direct Developer” (die uitsluitend verwijst naar een door Visa aan softwareontwikkelaars ter beschikking gestelde, vrij toegankelijke gesimuleerde testomgeving) alsof deze gelijkstaat aan het echte Visa Direct-netwerk, de gelicentieerde, gereguleerde infrastructuur waarmee banken en betalingsinstellingen daadwerkelijk geldmiddelen via het VisaNet-systeem verplaatsen.
In werkelijkheid heeft het Visa Direct Developer-portaal geen enkele technische, financiële of operationele verbinding met VisaNet. Het kan geen toegang krijgen tot echte gelden, geen echte transacties initiëren en niet communiceren met een echte betaalkaart of een echt banksysteem. De gehele omgeving is een sandbox, een softwaresimulator, die uitsluitend is bedoeld voor het testen van code. Elke transactie die binnen die omgeving wordt “verzonden”, geeft vooraf vastgelegde, volledig fictieve antwoorden in JSON-formaat terug, uitsluitend om programmeurs te ondersteunen bij de software-integratie.
Er wordt nooit echt geld verplaatst, geen enkele transactie bereikt een actieve kaart of rekening, en geen enkele in de sandbox getoonde identificatiecode bestaat in een echt Visa-systeem.
Iedereen die beweert reeds tegoeden te hebben "verzonden" met Visa Direct Developer, met name door schermafbeeldingen uit het ontwikkelaarsportaal of JSON-uitvoer met velden zoals "transactionIdentifier" te tonen, verstrekt dan ook ontegenzeggelijk valse informatie. Het betreft een frauduleuze tactiek die bedoeld is om legitieme geldstromen na te bootsen, terwijl er in werkelijkheid nooit een betaling is verricht en dat ook niet mogelijk was. De sandbox is evenmin verbonden met het financiële stelsel als een rekenmachine-app met uw bankrekening.
Hieronder volgt een forensische uiteenzetting van de wijze waarop fraudeurs dat misverstand als wapen gebruiken.
| Fase | Werkwijze van de fraudeur | Waarom het aannemelijk lijkt | Wat er in werkelijkheid gebeurt |
|---|---|---|---|
| 1 – Inrichting | Registreert een ontwikkelaarsaccount (zonder vergunning, zonder due diligence) en genereert voorbeeld-API-sleutels en testkaartnummers. | Iedereen kan dit binnen enkele minuten doen, wat een schijn van legitimiteit wekt. | Sandboxsleutels zijn gescheiden van het live netwerk; er kunnen geen middelen worden overgemaakt. |
| 2 – Vals "Bewijs van middelen" | Voert een PushFunds-aanroep uit in de sandbox, legt de HTTP 200 OK-respons en de gefabriceerde transactionIdentifier vast. Presenteert deze als schermafbeeldingen of pdf-“bewijzen van ontvangst”. | De responspayload lijkt identiek aan die van een live Original Credit Transaction (OCT). | De identificatiecode bestaat uitsluitend in de database van de sandbox; zij wordt nooit doorgegeven aan Visa Net. |
| 3 – Het slachtoffer tot commitment bewegen | Beweringen dat de middelen “reeds onderweg zijn maar in afwachting van compliance” en een eis om vooraf kosten te betalen (belasting, vrijgavekosten, AML-goedkeuring, enz.). | Het slachtoffer kan verifiëren dat het PAN in de payload bij zijn kaart hoort; de JSON bevestigt het exacte bedrag: een krachtig psychologisch bewijs. | Geen enkele acquiring BIN in de aanroep is actief, waardoor de betaling nooit kan worden verrekend. |
| 4 – Vertraging en uitvluchten | Beroept zich op “grensoverschrijdende vertraging”, “achterstand in de Visa-wachtrij” of “ontvangende bank niet geschikt voor Visa Direct” om tijd te winnen nadat de kosten zijn betaald. | Technisch jargon vertroebelt de kwestie, en het slachtoffer beschikt niet over de schemakennis om dit te weerleggen. | Uiteindelijk stopt de communicatie of verzoekt de fraudeur om verdere betalingen. |
Waarschuwingssignalen
| Indicator | Waarom het in een productieomgeving onmogelijk is |
|---|---|
| “Verzonden via Visa Direct Developer vanuit onze treasury” | Ontwikkelaarsportaal ≠ live push-betalingsrail. |
| Schermafbeeldingen tonen een test-Acquiring-BIN (normaal 4 × 0 of 4 × 9) | Test-BIN's zijn nooit routeerbaar via Visa Net. |
| Geen gelicentieerde sponsor/acquirer genoemd; afzender is een particulier of een obscure LLC | Visa vereist sponsoring door een acquirer voordat een project in productie gaat. |
| Vooraf te betalen "vrijgavevergoeding" vereist | Klassiek patroon van voorschotfraude; legitieme OCT's bereiken de begunstigde zonder extra kosten voor het slachtoffer. |
Hoe de authenticiteit te verifiëren (technische checklist)
- Vraag het actuele Original Credit Transaction (OCT)-record op bij de acquirer van de afzender; dit record zal niet bestaan.
- Vraag uw uitgevende bank of er op het live netwerk een overeenkomstige Visa-transactie-identificatie bestaat; een sandbox-identificatie bestaat daar niet.
- Controleer de BIN in het veld acquiringBin: waarden zoals 408999, 000000 of elke waarde die niet in de openbare BIN-database voorkomt, duiden op testgegevens.
- Vraag uw uitgevende bank of de acquirer van de afzender te bevestigen of de transactionIdentifier bestaat op het actieve netwerk.
Risicobeperking en alternatieve beveiligde routes
Kernboodschap in één zin
Indien een tegenpartij beweert „geld te hebben verzonden via Visa Direct Developer” en deze bewering onderbouwt met screenshots uit de sandbox, beschouw dit dan als doorslaggevend bewijs van voorschotfraude: de sandbox is een demonstratieomgeving, geen betalingsinfrastructuur, en er kunnen nooit middelen worden ontvangen.
Volgende stap
Een kennismaking aanvragen
Vertelt u ons in enkele regels wie u bent en wat u voor ogen heeft. Uw aanvraag gaat rechtstreeks naar de Bank en wordt vertrouwelijk behandeld.
Spreekt u liever met ons? Plan een videoconferentie van 30 minuten.