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 and Verification of Payee on sandbox are simulated and free. Both outcomes are driven entirely by the names you choose (below), so you can exercise every flow deterministically.

Driving the screening outcome with names

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

Driving the Verification of Payee outcome with names

The declared payee's full name (first + last, or the company name; matched trimmed and case-insensitively) selects the result:

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. A sandbox user without consent on an enabled application exercises the same gating as production: third-party declarations and payouts refuse with 31128.

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.

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 payee declaration (Whitelist Destination IBAN): beneficiaryType + firstName/lastName (or name for a company), or ownAccount: true. The response carries the simulated vop result (names table above). Declaring a payee on an existing row via POST /wallets/whitelist-iban/payee works on sandbox too. 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 + declaration).
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 payee 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.