Testing

The Twikey beta environment lets you simulate real payment and signing flows without touching live money or data. This guide covers everything you need to know to test your integration end-to-end before going live.

Transaction outcomes

Every 30 minutes, a job runs that simulates bank feedback on pending transactions. The outcome is determined by the transaction amount, making it easy to trigger specific states in your dunning configuration.

To mimic live bank behavior, the first feedback is always PAID. The actual outcome is returned on the second run of the job.

Use these amounts to verify your failed payment flows and dunning steps.

Dunning

Grace periods defined in dunning steps are compressed in the beta environment: each day becomes one minute. This allows you to verify your full dunning sequence without waiting days between steps. The shorter the configured grace period, the faster the next dunning step is triggered.

Wire transfers

You can simulate a wire transfer to test automatic and manual payment matching. Replace the IBAN in the header with an actual account from one of your bank gateways, then create a CSV file with the following format:

twikey:BE123456789123
name;iban;bic;msg;amount
John Doe;BE31798258915655;GKCCBEBB;My product;100

Note: amounts are in cents.

Upload the file via Reconciliation → Upload account info. The filename must be unique for each upload.

For automatic invoice matching, the msg field must match the payment reference of an existing invoice, and the amount must match exactly. When both conditions are met, the invoice is marked as paid reflecting actual reconciliation rules.

B2B mandate acceptance

A job runs every 30 minutes to simulate bank acceptance or rejection of B2B mandates. The outcome depends on the last digit of the IBAN:

• Even last digit: mandate accepted
• Odd last digit: mandate rejected

This does not apply to Belfius (BIC: GKCCBEBB) and BNP (BIC: GEBABEBB) accounts, which follow a different flow.

For automated testing, these IBANs give predictable results:

Connected banks only. For Dutch B2B signing, outcomes can be simulated via iDEAL/eMachtiging (see below). For non-connected banks, only the print and mark-as-signed flows are available.

B2B validation for non-connected banks

Any non-connected B2B-enabled account can be used — the behavior is always determined by the last digit of the IBAN.

Simulating feedback

The job must run twice to produce a final outcome, matching live bank behavior. For successful validations, a follow-up task is scheduled to run after 4 hours to mark the mandate as accepted. Using an IBAN ending in 00 skips the delay and signs the mandate immediately after the second job run.

Note: Due to the scheduled validation task, you may receive an additional webhook for the same mandate. This is expected behavior in beta and does not occur in production.

Signing methods

iDEAL, eMachtiging, and iDIN

Contact your customer success agent to link your template to a test bank. Provide the template ID and the signing method you want to test.

When using iDIN for signing or identification, the customer data is automatically overwritten to simulate data returned from iDIN as it would be in production. This behavior can be disabled or customized by your customer success agent.

A delay can also be configured for these methods. The delay is applied in the backend — on the frontend the customer proceeds to the verification page immediately, and the transaction result is confirmed on the next periodic run.

Other signing methods

eID: use your own personal eID card.

Bank cards (Maestro): use any valid card number, e.g. 4111111111111111. The outcome depends on the expiry month:

SMS: when inviting a customer to sign via SMS, a mock email is sent to the address configured under Settings → Company information. Open the link in that email, then:

• Enter OK for a successful outcome
• Enter any other value to simulate a failure

Payment links and QR codes

When using the X-Purpose header in the beta environment, QR codes generated from payment links cannot be scanned by bank apps. Only production environment links produce valid QR codes for bank apps.

The payment link URL itself works normally in beta — only the QR code rendering is affected.

iDEAL 2.0

To test iDEAL 2.0 one-off payments, add a test provider via Payment Hub → Add → Payment Provider → iDEAL 2.0:

• Merchant ID: any number
• SubId: leave empty
• Select Test bank
• Optionally link it directly to a profile, or configure it on one afterward

The iDEAL mock can be used for direct payment of invoices and payment links. To use it for signing with first payment, contact support to enable it as a signing method.

In the iDEAL mock payment flow, you can select different outcomes directly.

Webhooks

You can test webhook delivery to verify that your endpoint handles events correctly and that the signature validation is working. When activating webhooks via the API settings, no query parameters are required in the URL — Twikey adds the appropriate parameters when sending each request, and they vary depending on the event type.

See the webhook reference for a full list of event types and their payloads.

Collection agency

After a transaction is sent to the collection agency, feedback is simulated every 15 minutes until the case is closed. Use the following amounts to trigger specific outcomes:

Letters

No real letters are sent in the beta environment. Instead, a copy of the letter is sent by email to the user who triggered the action, so you can verify the content before going live.

WIK letters must be released by your customer success agent. Once released, you receive a zip file containing the PDFs at the email address configured under Settings → Company information.