Use bank account details from a Mollie iDEAL payment only as an optional, controlled addition to an AFAS debtor record. Link the payment, order and debtor through reliable identities and let your own policy determine whether the workflow may be active. An IBAN from one payment is not general proof for every business relationship or payment method.
Payment data is not unrestricted master data
A payment may be made by a partner, staff member or another account holder. The account used to pay for one order therefore need not be the debtor’s regular account. Bank details are also sensitive. Collect and show only what the agreed process needs, limit access and agree the retention period and lawful basis with the person responsible for privacy.
Technically, the route must connect three identities: the Mollie iDEAL payment, WooCommerce order and confirmed AFAS debtor. If one link is missing, the optional addition must not start. The capability in Connect must be explicitly activated and configured; its presence in the software is not permission to use other Mollie payment methods or every payment as a master data source.
Data minimisation map
| Data | Purpose | Safe handling |
|---|---|---|
| Payment ID | Demonstrably link the transaction | Retain exactly within the workspace |
| Order reference | Connect the payment to the sale | Validate against the source order |
| Debtor ID | Select the correct AFAS business relation | Use only a confirmed identity |
| IBAN/account details | Approved enrichment | Limit display and do not overwrite blindly |
| Account holder name | Possible consistency check | Not as the sole proof of identity |
For each field, record whether you store it, only pass it on or delete it after processing. Let security and privacy policy take precedence over debugging convenience.
Fictional example: payment by the holding company
Fictional example of a recommended process: branch De Kleine Werf places order DKW-204, but the holding company pays through iDEAL. The team has decided beforehand that third-party payments must not automatically serve as master data. An authorised staff member assesses the account holder according to that policy and leaves the branch’s existing primary IBAN unchanged.
In a second fictional case, the payment, order and confirmed debtor match, and the bank account does not yet exist in AFAS. Under the approved policy, the activated iDEAL workflow can then submit an additional account without adding an existing match twice. The audit trail retains which payment triggered the attempt. Comparing against a holding company and any review task are process advice here, not a claim that software automatically recognises every name discrepancy. The example is not legal or financial advice.
Checks before automatic enrichment
- Is the payment ID unique and confirmed within the correct Mollie account?
- Has the exact order been found in the same workspace and store?
- Does the order have an unambiguous AFAS debtor identity?
- Is this demonstrably an iDEAL payment that policy permits as a data source?
- Are you adding an account or overwriting an existing primary account?
- Is a discrepancy visible without distributing bank details more widely?
- Can an employee trace which payment caused the change?
In Desk only the context needed for the role should appear. Find more about reliable identity chains in integrating an online store and ERP. Include privacy, authorisation and change history in the same acceptance test.
Separate enrichment from primary order processing. A paid order should not stall because an optional bank detail cannot be added. Let the order flow complete on its own evidence and run iDEAL enrichment as a separate, repeatable provider step. A discrepancy must not block the core order, parcel or delivery. This also makes switching it off easier when privacy policy or the business process changes.
Test an existing IBAN, missing IBAN, third-party payment, two debtor candidates and a refund without new account information. Check who can see and approve the change, and whether exports spread the value unnecessarily. Include logging: do not write the full bank number into general errors. Where possible, use masked displays and an internal identity. Have a periodic review show how many additions were automatic, skipped or manually assessed, and remove rules that no longer have a demonstrable process purpose.
Describe the deletion and correction route too. An incorrectly linked account detail must be demonstrably correctable without changing the historical payment. Restrict that permission, record actor and reason, and check whether caches or exports still contain the old value. A good enrichment feature also includes a safe way back.
Want to use iDEAL payment data under control without contaminating master data? Have Yindle define the identity and policy boundaries.