EUR payment accounts on dedicated IBANs to send/receive from third parties
AvailabilityPayment Accounts are enabled per application after a Payment Accounts agreement is signed with Lightspark Payments Europe. Contact your account manager to get started.
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. See Third-Party SEPA Payins.
- Send payments to third parties. The feature also enables third-party SEPA payouts: declared beneficiary names on IBAN whitelisting and on ad-hoc bank transfers. 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.
Eligibility and gating
A user transacts under Payment Account rules only when both are true:
| Gate | Set by |
|---|---|
| The application has Payment Accounts enabled | Lightspark Payments Europe, after the agreement is signed |
| The user (or business) has recorded consent to the Payment Account terms | Your application, via the consent endpoints |
A user without recorded consent keeps the previous behavior in every respect, even on an enabled application - so you can roll consent collection out gradually. KYC requirements, account statuses, and limits work exactly as before.
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 - Please use the
ipfield to accurately record the IP address of the end user. - 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.
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
Two things, both small:
- Record each user's consent to the Payment Account terms before they can use Payment Account features
- Review the behavior notes in Third-Party SEPA Payins. No schemas change and no new webhook types are introduced, but the timing of two existing webhooks changes for Payment Account payins, statements gain two row semantics you should deduplicate correctly, and statements can contain
MANUAL_ADJUSTMENTentries you should render neutrally.
If you send outgoing third-party payments, also review Third-Party SEPA Payouts. To try the full flow end to end before production, see Testing in Sandbox.