Testing in Sandbox

Everything on this page is self-serve on the sandbox environment — you do not need to contact us to try Payment Accounts there. The Simulator in your sandbox partner dashboard has a Payment Accounts section with three tabs: Payment Accounts, SEPA Payin (3P), and SEPA Payout (3P).

Screening on sandbox is simulated and simulated screenings are free. The screening outcome is driven entirely by the sender or beneficiary name you choose (see below), so you can exercise both the clear and the blocked flows deterministically.

Driving the screening outcome with names

This convention applies to the payin senderName and to the declared beneficiary name on payouts alike.

1. Enable the feature and record consent

On the Payment Accounts tab:

• Enable Payment Accounts for your sandbox application with the toggle. On production this is done by Lightspark Payments Europe after the agreement is signed; on sandbox you flip it yourself. The tab also shows the resulting state, including whether third-party SEPA payouts are effectively enabled.
• Record consent for a test user by entering their userId and choosing accepted or not. This performs the same consent recording as POST /user/payment-account/consent — you can equally call the API yourself; the tab is just the quickest way to get a user gated in.

Remember: a user transacts under Payment Account rules only when the application flag and the user's consent are both in place.

2. Simulate a third-party payin

On the SEPA Payin (3P) tab, send a simulated incoming SEPA transfer:

• accountId — the user's EUR account to credit.
• amount — in cents (e.g. 10000 = 100.00 EUR).
• senderName — the name of the simulated sender. Use a name different from the account holder's KYC name to make the payin third-party; a name matching the account holder exercises the unchanged first-party flow.
• Sender IBAN/BIC and a payment reference, optionally.

What to observe, per Third-Party SEPA Payins:

• Clear sender name: the immediate SEPA_PAYIN_COMPLETED webhook at receipt, then the APPLICATION_FEE event once the simulated screening clears.
• Sanction-matching sender name: the payin is credited and then taken back — a SEPA_PAYIN_REVERTED debit appears on the account statement with the same bankingTransactionId as the credit, and no fee is collected.

3. Simulate a third-party payout

The SEPA Payout (3P) tab walks the full outgoing flow described in Third-Party SEPA Payouts:

1. Whitelist a beneficiary — userId, destination IBAN + BIC, and the declared beneficiary name (the name field of Whitelist Destination IBAN). You can also list the user's whitelisted IBANs from here.
2. Initiate a payout — userId, source accountId, and amount, against either the whitelistedIbanId or a raw destination (IBAN + BIC + declared name).
3. Confirm the transaction — with the challengeId from the initiate step. As with the rest of the sandbox environment, no SMS is actually sent and the verification code is always 123456.
4. Update the payout status — drive the simulated bank leg to COMPLETED or FAILED (by accountId + transactionId) to receive the corresponding SEPA_PAYOUT_COMPLETED / SEPA_PAYOUT_FAILED webhooks.

A beneficiary whose declared name matches the sanctions convention above exercises the held flow: the payout is accepted but paused for review instead of proceeding. A clear name proceeds normally once screening completes.