Payment Accounts

What is a Payment Account?

A Payment Account is a user's EUR account, upgraded to a full e-money payment account. It keeps the same accountId and the same IBAN your integration already uses. What changes is what the account can do:

• Receive payments from anyone. Incoming SEPA transfers no longer need to originate from an account held in your user's own name. A third-party payment is held under a lien until the sender's sanctions screening concludes — typically seconds — and only then credited. See Third-Party SEPA Payins.
• Send payments to third parties. Every payout destination carries a declared payee (the user's own account, or a third party by name), verified against the payee's bank (Verification of Payee) and screened before funds move. See Third-Party SEPA Payouts.

The account's internal identifier remains accountId; the IBAN attached to the account (in bankingDetails on the account object) is the address the outside world uses to reach it. Both are unchanged by this feature. On conversion the account additionally receives a ten-digit paymentAccountNumber.

Eligibility and gating

A user transacts under Payment Account rules only when both are true:

Consent can be rolled out gradually. Note, however, that on an enabled application a user without recorded consent is gated, not grandfathered: a EUR balance that is not a payment account cannot pay or be paid by third parties. For such users expect 403 / errorCode: "31128" on third-party whitelisting and third-party payouts, and note that euro transfers between accounts on the platform require a payment account on both sides. Payouts to the user's own external account remain possible: the platform verifies the account is really theirs through the SEPA Verification of Payee scheme before allowing the payment. KYC requirements, account statuses, crypto and card behavior are unchanged.

Recording consent

Consent must be recorded before a user or business transacts under Payment Account rules. One POST call per user (or business):

• Record consent (consumer) — POST /user/payment-account/consent
• Read consent (consumer) — POST /user/payment-account/consent/get
• Record consent (business) — POST /business/payment-account/consent
• Read consent (business) — POST /business/payment-account/consent/get

Key points:

• Callable before KYC/KYB — collect consent during signup for new users, before KYC. For existing users, collect it the next time they open your app. Consent from a suspended user is also accepted.
• Pass the end user's IP explicitly — use the ip field to accurately record the IP address of the end user.
• The first acceptance wins. Re-posting accepted: true for a user who already consented does not move the recorded acceptance date — the original consent record is preserved.
• Consumers and businesses each carry their own consent record. For a business, consent is recorded once for the business entity (by its director / primary user in your app), not per member. Your own corporate account's consent is recorded by Lightspark Payments Europe when the agreement is signed and there is no API call for it.

Acceptance converts the user's existing EUR accounts into payment accounts in place — the balance at conversion is recorded as the e-money issuance snapshot and re-verified against the settled ledger shortly afterwards. No new accounts, no identifiers change.

Terms to display

The Payment Account terms document is provided by Lightspark Payments Europe alongside your agreement. Display it to the user at the point of consent, and pass the version you displayed (termsVersion) and where it is hosted (termsUri) in the consent call so the record is complete.

Integration checklist

Consent is the first step, not the whole integration. In full:

1. Record each user's consent to the Payment Account terms (above).
2. Declare the payee on every payout destination. New optional fields on Whitelist Destination IBAN declare the payee at whitelisting; IBANs whitelisted before Payment Accounts have no declared payee and must be declared once via POST /wallets/whitelist-iban/payee — a payout to an undeclared destination is refused with errorCode: "30080". See Third-Party SEPA Payouts.
3. Confirm every payout with SCA. Payout initiation returns a challengeId; confirmation requires the verification code and the end user's ip — see Strong Customer Authentication. If your integration already drives the SMS confirmation flow, nothing new is needed here.
4. Display the Verification of Payee result (vop on the whitelist row) to the paying user before they authorise — in particular the bank-corrected name on a close match, and a clear warning on a no-match.
5. Handle held inbound payments. A third-party payin can be held under a lien before crediting: the account carries a lienAmount, the statement shows a provisional status: "LIEN" row, and the SEPA_PAYIN_COMPLETED webhook arrives at credit time, not at receipt. See Third-Party SEPA Payins.
6. Know the limits and fee model. Users can set SEPA Instant sending limits under SCA (over-limit payments are refused), and payout fees are charged on top of the payment amount, so the balance must cover amount + fee.

To try the full flow end to end before production, see Testing in Sandbox.