A Dutch webshop has switched its checkout to Wero. A customer then returns an item bought through iDEAL before the change. Support opens the order, sees the new payment interface and cannot tell which refund route still applies. The launch succeeded, but the earlier transactions still need an operational home.
For a retailer preparing its iDEAL-to-Wero transition, this is a more useful software brief than “add Wero”. The checkout may already be handled by a provider. The missing work is a controlled coexistence period: old and new orders remain searchable, refunds follow the supported route, and finance can explain both generations.
Start with your provider's migration plan
The Dutch Payments Association's July 2026 announcement describes a further migration phase beginning in October and a joint target of completing the transition by the end of 2027. That is programme context, not a universal instruction to replace every merchant integration on the same day.
Provider schedules are more specific. ABN AMRO's merchant guidance describes its own staged transition and technical migration options. Check the current instructions for your actual contract before commissioning changes. Information reviewed on 12 October 2026 can change as the rollout progresses.
Ask the provider which responsibilities it absorbs and which remain yours. Hosted checkout branding, custom checkout components, payment identifiers, refund operations and settlement exports may have different owners. A proposal that charges for a complete payment rebuild should explain why a smaller integration change would not achieve the required outcome.
Preserve the history that survives the checkout change
An order should keep its stable internal reference throughout the migration. Attach the original payment method, provider account, transaction reference and integration version where relevant. These are historical facts, not labels to replace when the website's branding changes.
Ask the provider which historical lookup and refund operations remain available under your contract. Establish whether an account change, a new API or a platform plugin affects those operations. Do not assume that old identifiers can be passed to a new endpoint merely because both integrations belong to the same provider.
The support interface should present one order history while choosing the correct supported operation behind it. Where an automated route is unavailable, show an owned manual procedure. Hiding historic orders in an abandoned dashboard transfers the migration cost to customer service.
Route events to the transaction they actually describe
Payment notifications are part of the workflow, but their exact behaviour belongs to the chosen provider and API version. For example, Mollie's webhook documentation instructs an integration to retrieve the current resource through its API after receiving a notification. It also describes notifications associated with refund state changes. Do not assume that another provider uses identical events or payloads.
During coexistence, an event may concern a transaction created before the checkout change. The integration should identify its merchant account and payment record before deciding how to retrieve the current state. Preserve any necessary old event handling until the agreed retirement conditions are met; disabling it on launch day may hide outstanding work.
Test an order initiated before the cutover whose status changes afterwards. Repeated notifications should update the known record without repeating fulfilment. An unfamiliar reference belongs in an investigation queue with an owner, rather than being discarded because it does not match the new format.
Make the old-order refund a migration acceptance test
Choose a historical iDEAL order and a new Wero order for the acceptance demonstration. For each, the operator should find the original transaction, record an authorised refund decision and identify the provider-supported action. Use sandbox data or an agreed controlled test process rather than issuing unsolicited refunds to customers.
Include a response interrupted after submission. The next operator needs to see the unresolved request and its reference before attempting another action. Recovery must use the provider's documented lookup and retry behaviour. A migration is not a reason to guess whether money moved or assume every payment method supports the same refund features.
Agree who keeps the historical route operational and who authorises its eventual retirement. The relevant period depends on your business obligations, provider terms and unresolved transactions. Put those dependencies in the handover instead of selecting an arbitrary shutdown date.
Give finance a reconcilable view
Finance needs to trace totals back to individual records. A useful view separates gross sales, approved refunds, provider-reported refund states, fees and settlement references where the provider makes them available. Do not describe an order as settled solely because it was paid.
Obtain sample settlement exports from the current and proposed arrangements. Check identifiers, dates and field meanings instead of assuming a familiar column name has retained its meaning. A refund for a pre-migration sale must remain traceable even when it appears in a later reporting period or a changed export format.
Start by comparing the integration with the team's existing closing process. Measure unexplained items and the effort required to resolve them against your own baseline. A supplier cannot credibly promise a universal percentage improvement before seeing how your orders and finance records behave.
Set cutover criteria and name the decision owner
A sensible first scope covers one storefront, one provider account, the relevant order system and a defined refund journey. Include support permissions, export formats, monitoring and instructions for provider changes. Decide who maintains the integration when an API version or settlement file changes.
Define release criteria with support and finance: historical orders remain accessible, agreed refund paths work, sample settlements reconcile, and a named owner can resolve exceptions. Document which changes can be reversed under the provider's migration plan. An application rollback must not pretend to reverse an external provider transition that has already occurred.
Our guide to scoping an API integration partner in the Netherlands explains how to put failure scenarios into a project brief. The software project handover guide helps you define what your team receives at release.
TuniCyberLabs can build the missing connection through custom software development. Share your checkout platform, provider migration plan and historic refund workflow to scope a transition your operations team can actually verify.