Event Simulator

The Event Simulator lets you simulate events that happen in production — incoming transactions, outgoing payments, and bank status updates — so you can test your full integration in sandbox.

For the full end-to-end testing workflow, see Testing Complete Payment Flows in Sandbox.

---

Overview

The Event Simulator supports three types of simulation:

Access the Event Simulator: Console > Developers > Event Simulator

---

Simulate a pay-in (Credit)

Simulates receiving funds from a debtor (payer) on your Fintecture acquiring account. In production, this happens when the payer's bank executes the transfer. In sandbox, you trigger it manually.

When to use

• After a payment reaches payment_created on an acquiring account — to confirm settlement (transfer_state: received). See Phase 3 — Settlement for the full workflow
• For Smart Transfer — to simulate the payer sending the bank transfer to the virtual IBAN. See Smart Transfer scenarios for how to reach payment_pending first
• To test partial payments (send less than expected) or overpayments (send more)

How to simulate

1. Go to Developers > Event Simulator
2. Select Credit type
3. Fill in the required fields: amount, currency, debtor name, creditor IBAN
4. Optionally add an internal reference and label
5. Click Simulate event

Shortcut: From a payment's detail page, click Actions > Simulate event to pre-fill all fields automatically.

What happens

• A credit transaction is created on the acquiring account
• If the transaction matches a pending payment session (by IBAN + amount for Smart Transfer, or by reconciliation), the session's transfer_state updates to received
• Configured webhooks are triggered
• The payment status will update within seconds

---

Simulate a debit (refund or payout)

Simulates an outgoing payment from your Fintecture acquiring account. In production, Fintecture initiates the SEPA transfer. In sandbox, you simulate the bank confirming the execution.

When to use

• To complete a refund — after creating the refund via Console. See Testing refunds for the full workflow
• To complete a payout — after creating the payout via Console. See Testing payouts for the full workflow

Refund flow

1. Go to the payment in Console > click Actions > Refund
2. Choose partial or full refund and confirm
3. Open the refund payment details (click the refund row in the payment list)
4. Click Actions > Simulate event — this redirects to the Event Simulator with pre-filled data

Or manually:

1. Go to Developers > Event Simulator
2. Select Debit type
3. Enter the refund's session_id
4. Select the transaction status and optionally a transfer reason
5. Click Simulate event

Prerequisite (acquiring accounts): The original payment must have transfer_state: received before you can process a refund. Simulate a Credit first to achieve this.

Payout flow

1. Create a payout via Console (sidebar tab Payout), this will create a RequestForPayout session in status iban_required . The payee's IBAN is not yet known so an AIS step has to be performed using the retrieved Connect link.

   

2. Open the Connect link & perform the AIS step (e.g. select CIC bank -> login + click Authorize on CIC sandbox -> you will be redirected back to Connect with a selector to validate the IBAN to use -> click "Confirm")

   

3. After the Connect redirection confirm this account (the IBAN will now be set on the payment, session in iban_received & the payment will soon be initiated. Internally we create a debit transaction in status pending

   

4. The Connect payout status page should be displayed, your payout will soon transition from status iban_received to payment_pending once the debit transaction executes in our Sandbox

   

5. Then go to Developers > Event Simulator in the Console

6. Select Debit type, paste the payout session_id & fill the remaining fields. Use status Completed for a succesful payout or status Rejected for an unsuccessful scenario.

   1. Depending on the selected status, the debit transaction will be updated internally & the pps will also update & trigger webhooks. You can test different scenarios via the EventSimulator
   2. ⚠️If you don't perform this EventSimulator step, your payout session will remain payment_pending indefinitely

7. Click Simulate event, your payout session will update and you can refresh the Connect payout status page after this to see the final status

Form fields

Status options: Completed, Sent, Pending, Rejected, Returned

• Note: Sent is an intermediate status mapped to payment_pending, Returned is an edge case status where funds can be returned to the payout account if creditor bank refuses the funds. The transfer_state of such payout will be set to returned via webhook

Transfer reason (only when status is Rejected): insufficient_funds, closed_account, blocked_account, fraud_suspected, technical, unknown, customer, regulatory_reason, transaction_forbidden

What happens

• A debit transaction is created on the payout account & depending on the selected status in the EventSimulator, the payout session status is updated
• Configured webhooks are triggered

---

Simulate a bank transition

Simulates the asynchronous status update that a bank sends to Fintecture after a payment is initiated. In production, this callback arrives automatically. In sandbox, you need to trigger it manually for payments left in payment_pending.

When to use

• When a payment is in payment_pending status and you want to move it to payment_created or payment_unsuccessful. See Phase 2 — Bank transition for when this fits in the testing workflow
• Sandbox only — this simulation is not available in production
• The session must currently be in payment_pending status. Use the Demo Bank to reach this state

How to simulate

1. Go to Developers > Event Simulator
2. Select Bank Transition type
3. Enter the payment's Session ID
4. Select the target session status:
   • payment_created — payment succeeds
   • payment_unsuccessful — payment fails
5. If payment_created: select transfer state (completed or received)
6. If payment_unsuccessful: optionally select a transfer reason
7. Click Simulate event

Form fields

Transfer reason options: insufficient_funds, closed_account, blocked_account, fraud_suspected, technical, unknown, customer, regulatory_reason, transaction_forbidden

What happens

• The payment session is updated to the new status — exactly as if the bank had sent the real callback
• All the logical events ensue: the corresponding webhooks and notification emails are sent
• You will see the updated status in the Console payment details page

Constraints

• Sandbox only — simulations are not available in production.
• payment_pending required — the session must currently be in payment_pending status.
• Valid transitions only — you cannot transition to the same status or to an invalid status.

After a successful bank transition

If the beneficiary is an acquiring account, transitioning to payment_created is only part of the flow. You still need to simulate a Credit transaction to confirm settlement — unless you used transfer_state: received in the transition, which is equivalent to simulating the credit transaction as well as receiving the payment_created status.

---

Summary — which simulation to use

---

Related guides