Gebruik bankrekeninggegevens uit een Mollie-iDEAL-betaling alleen als optionele, gecontroleerde aanvulling op een AFAS-debiteur. Koppel betaling, order en debiteur op betrouwbare identiteiten en laat eigen beleid bepalen of de workflow actief mag zijn. Een IBAN uit één betaling is geen algemeen bewijs voor iedere relatie of betaalmethode.
Betalingsdata is geen onbeperkte stamdata
Een betaling kan door een partner, medewerker of andere rekeninghouder worden gedaan. De rekening waarmee één order is betaald hoeft dus niet de vaste rekening van de debiteur te zijn. Bovendien zijn bankgegevens gevoelig. Verzamel en toon alleen wat nodig is voor het afgesproken proces, beperk toegang en leg bewaartermijn en rechtsgrond met de privacyverantwoordelijke vast.
Technisch moet de route drie identiteiten verbinden: Mollie-iDEAL-betaling, WooCommerce-order en bevestigde AFAS-debiteur. Ontbreekt één schakel, dan hoort de optionele aanvulling niet te starten. De mogelijkheid in Connect moet expliciet geactiveerd en geconfigureerd zijn; aanwezigheid in software is geen toestemming om andere Mollie-betaalmethoden of iedere betaling als stamdatabron te gebruiken.
Dataminimalisatiekaart
| Gegeven | Doel | Veilige behandeling |
|---|---|---|
| Payment-ID | Transactie aantoonbaar koppelen | Exact bewaren binnen werkruimte |
| Orderreferentie | Betaling aan verkoop verbinden | Valideren tegen bronorder |
| Debiteur-ID | Juiste AFAS-relatie kiezen | Alleen bevestigde identiteit gebruiken |
| IBAN/rekeningdetail | Goedgekeurde verrijking | Beperkt tonen en niet blind overschrijven |
| Naam rekeninghouder | Eventuele consistentiecontrole | Niet als enig identiteitsbewijs |
Leg per veld vast of je het opslaat, alleen doorgeeft of na verwerking verwijdert. Laat beveiliging en privacybeleid leidend zijn, niet gemak voor debugging.
Fictief voorbeeld: betaling door de holding
Fictief voorbeeld als aanbevolen proces: vestiging De Kleine Werf plaatst order DKW-204, maar de holding betaalt via iDEAL. Het team heeft vooraf bepaald dat betalingen door derden niet automatisch als stamdata mogen dienen. Een bevoegde medewerker beoordeelt de rekeninghouder volgens dat beleid en laat het bestaande primaire IBAN van de vestiging ongemoeid.
In een tweede fictief geval horen payment, order en bevestigde debiteur bij elkaar en bestaat de bankrekening nog niet in AFAS. De geactiveerde iDEAL-workflow kan dan volgens het goedgekeurde beleid een aanvullende rekening aanbieden en een bestaande match niet dubbel toevoegen. Het auditspoor bewaart welke betaling de poging veroorzaakte. De vergelijking met een holding en eventuele beoordelingstaak zijn hier procesadvies, geen claim dat software iedere naamsafwijking automatisch herkent. Het voorbeeld is geen juridisch of financieel advies.
Poorten vóór automatische verrijking
- Is de payment-ID uniek en bevestigd binnen het juiste Mollie-account?
- Is de order exact gevonden in dezelfde werkruimte en winkel?
- Heeft de order een ondubbelzinnige AFAS-debiteuridentiteit?
- Is dit aantoonbaar een iDEAL-betaling die volgens beleid als databron mag dienen?
- Voeg je toe of overschrijf je een bestaande primaire rekening?
- Wordt een verschil zichtbaar zonder bankdata breder te verspreiden?
- Kan een medewerker herleiden welke betaling de wijziging veroorzaakte?
In Desk hoort alleen de voor de rol benodigde context te verschijnen. Meer over betrouwbare identiteitsketens vind je bij webshop en ERP koppelen. Neem privacy, autorisatie en wijzigingshistorie op in dezelfde acceptatietest.
Maak verrijking los van de primaire orderverwerking. Een betaalde order moet niet blijven hangen omdat een optioneel bankdetail niet kan worden aangevuld. Laat de orderflow afronden volgens haar eigen bewijs en voer de iDEAL-verrijking als afzonderlijke, herhaalbare providerstap uit. Een afwijking moet de kernorder, het pakket of de levering niet blokkeren. Dit maakt ook uitschakelen eenvoudiger wanneer privacybeleid of bedrijfsproces verandert.
Test met een bestaand IBAN, ontbrekend IBAN, betaling door een derde, twee debiteurkandidaten en een refund zonder nieuwe rekeninginformatie. Controleer wie de wijziging kan zien, wie haar kan goedkeuren en of exports de waarde onnodig verspreiden. Neem logging mee: schrijf niet het volledige banknummer in algemene foutmeldingen. Gebruik waar mogelijk gemaskeerde weergave en een interne identiteit. Laat een periodieke review zien hoeveel aanvullingen automatisch, overgeslagen of handmatig beoordeeld zijn en verwijder regels die geen aantoonbaar procesdoel meer hebben.
Beschrijf ook de verwijder- en correctieroute. Een fout gekoppeld rekeningdetail moet aantoonbaar kunnen worden hersteld zonder de historische betaling te veranderen. Beperk die bevoegdheid, leg actor en reden vast en controleer of caches of exports de oude waarde nog bevatten. Een goede verrijkingsfunctie omvat dus ook een veilige weg terug.
Wil je iDEAL-betaaldata gecontroleerd gebruiken zonder stamdata te vervuilen? Laat Yindle de identiteits- en beleidsgrenzen uitwerken.