--- title: "API Integration" slug: "api-integration-2" updated: 2026-07-08T19:34:30Z published: 2026-07-08T19:34:30Z canonical: "www.documentation.paynetics.digital/api-integration-2" --- > ## Documentation Index > Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt > Use this file to discover all available pages before exploring further. # API Integration Paynetics' API Integration channel lets you build your own branded web or mobile application and deliver Paynetics payment services directly through it. You write the front-end; Paynetics provides the regulated infrastructure — payment accounts, card issuing, transfers, and acquiring — through a single REST API under your brand and your experience. This is the channel to choose when you want full control over the product and user interface and are comfortable building and maintaining the integration yourself. If you prefer a production-ready mobile wallet that you can brand without building it, see [White Label App](/docs/white-label-app). If you are running your own card programme on a Paynetics-sponsored BIN, see [BIN Sponsorship](/docs/bin-sponsorship). --- ## What You Can Build API Integration supports a wide range of use cases across Paynetics' product lines: | Use Case | Products Used | | --- | --- | | Consumer fintech or neobank | Embedded Finance — IBAN accounts, virtual and physical cards, transfers | | Corporate expense management | Embedded Finance — business accounts, commercial cards, per-card controls, real-time transaction webhooks | | Marketplace payouts | Embedded Finance — seller accounts, batch fund loading, SEPA / Faster Payments withdrawals | | B2B banking-as-a-service | Embedded Finance — multi-currency accounts, commercial cards, custom fees | | Online payment acceptance | Acquiring — card acceptance, 3DS, tokenisation, AFT, OCT | | Reward and incentive loading | Embedded Finance — funding accounts, batch card top-up | Most partners integrate Embedded Finance. Acquiring can be added as a standalone channel or combined with Embedded Finance in the same instance. --- ## Available Products ### Embedded Finance The core of API Integration. Gives you access to the full Paynetics platform object model: **Instance → Program → Account → Balance → Card**. **Payment Accounts** — Open payment accounts for consumers and businesses across the EU, UK, Iceland, Norway, and Liechtenstein. Supports EUR (IBAN, SEPA), GBP (Sort Code + Account Number, Faster Payments), BGN (IBAN, BISERA), and USD (inbound SWIFT for business accounts). **Card Issuing** — Issue Mastercard and Visa virtual and physical cards linked to Account Balances. Configure usage groups, velocity limits, MCC whitelists, and per-card fee groups via API. Apple Pay and Google Pay push provisioning is available for certified programmes. **Transfers** — SEPA Credit Transfer, SEPA Instant, Faster Payments, CHAPS (inbound), BISERA, SWIFT (inbound), and instant internal transfers between Paynetics Accounts. **Customer Onboarding** — Onboard natural persons and legal entities via the Onboarding API. Choose between Paynetics Managed KYC (Paynetics verifies using its own vendors) or Partner Managed KYC (you verify using Paynetics-approved vendors and submit results in real time). **Partner Portal** — A web portal for your operations team to manage accounts, cards, and transactions without API calls: view balances, block/unblock accounts, review transaction history, and upload batch files for card issuance or customer onboarding. See [Embedded Finance Overview](/docs/embedded-finance-overview) for the full capability reference. ### Acquiring Available as an add-on or standalone. Lets you accept card payments via a hosted payment page or direct API integration. - Card acceptance with 3DS authentication - Account Funding Transactions (AFT) for top-up use cases - Original Credit Transaction (OCT) for payouts to cards - Secure Card-on-File (SCOF) and Visa Tokenised Card-on-File (TCoF) - Click to Pay and Apple Pay / Google Pay acceptance --- ## How the Integration Works ### API Paynetics exposes a REST API over HTTPS. All requests are authenticated using **HMAC-SHA256** signing, which requires exchanging a public PGP key with Paynetics during onboarding to receive your API key and secret. The full API reference is published at [developers.paynetics.digital](https://developers.paynetics.digital). ### Webhooks Real-time event notifications are delivered to your registered endpoint via HTTPS POST. Webhooks cover the full event lifecycle: account and card status changes, transaction authorisations, KYC decisions, wire transfer receipts, and more. Paynetics requires webhook endpoints to be reachable at all times with sub-10-second response times. ### Sandbox Every partner receives a dedicated Sandbox Instance prior to production access. The sandbox mirrors your production configuration: the same programme, account types, fee groups, and API endpoints. Paynetics pre-loads 10,000 currency units to your funding account for testing, and a wire-in simulator is available to test inbound transfers at any time. Physical cards cannot be issued in the sandbox. --- ## Integration Requirements Paynetics requires all API Integration partners to meet the following before go-live: **Two-Factor Authentication (2FA)** — All user sign-in and account-recovery flows must use two factors: something the user knows (password, PIN) combined with something the user owns (OTP via SMS or email, authenticator app) or something the user is (biometric). An authorised device can count as the first factor if you can prove the transaction can only originate from it. **Strong Customer Authentication (SCA)** — All payment transactions must be authorised via SCA in line with PSD2 requirements. Your SCA implementation must be audited by a certified QSA (Qualified Security Assessor) and the audit report submitted to Paynetics before go-live. Paynetics can refer you to an approved security lab. **Operations Traceability** — You must implement immutable logging of all legal consents (e.g. Terms and Conditions acceptances) and all payment transaction authorisations executed via your UI. Minimum required fields per log record: operation type and details, device fingerprint, timestamp, and public IP address. Logs must be retained for at least five years and available to Paynetics within hours of a request. **Penetration Testing** — A pen test by a certified QSA covering your network, infrastructure, web interfaces, mobile apps, and APIs is required before go-live. If you have a passing pen test (no medium or high severity findings) from within the last 12 months, a limited re-test scoped to the changes made for the Paynetics integration is accepted. **UAT Testing** — Once sandbox integration is complete, you run a set of end-to-end integration tests defined by Paynetics to confirm data quality, business flow, KYC/AML policy compliance, and correct implementation of all agreed behaviours. Results are submitted to Paynetics for review. --- ## Choosing a Delivery Channel | | API Integration | White Label App | BIN Sponsorship | | --- | --- | --- | --- | | **You build the UI** | Yes — full control | No — Paynetics provides a brandable mobile app | Not applicable — card programme, no app required | | **Best for** | Custom web or mobile products, complex use cases, full UX ownership | Fast time-to-market for a consumer mobile wallet | Partners running their own card programme | | **Products available** | Embedded Finance + Acquiring | Digital Wallet (Issuing or Invite-Only) | Card issuing on partner-owned BIN | | **Integration effort** | High — you build and maintain the client | Low — branding and configuration only | Medium — API for card lifecycle and user management | | **Regulatory requirements** | SCA audit, pen test, 2FA, traceability | Handled by Paynetics (app is SCA-certified) | Programme Manager obligations; no separate SCA audit | --- ## Getting Started The integration journey follows the standard Paynetics partner process: 1. **Pre-vetting** — Paynetics performs initial due diligence on your business and use case. 2. **Product definition** — You define your payment products (programmes, account types, card products, fees, limits) with your assigned Project Manager. These are configured in your Sandbox Instance. 3. **Technical integration** — Your engineering team implements against the Sandbox API, supported by Paynetics technical engineers. 4. **Compliance and legal** — Underwriting review, SCA audit, pen test, marketing materials approval, and legal agreements run in parallel with technical integration. 5. **UAT** — End-to-end testing against a defined test suite. 6. **Go-live** — Production environment provisioned; all checklist items closed. For the full timeline and milestone breakdown, see [Partner Journey Overview](/docs/partner-journey-overview). For what happens at go-live and beyond, see [Go-Live](/docs/go-live). Bank Identification Number. The first 6 to 8 digits of a payment card number that identify the issuing institution and card scheme. The BIN determines the card network, issuer, and card type for routing and authorisation purposes. International Bank Account Number. A standardised international format for identifying a bank account. In the Paynetics platform, IBANs are assigned at the Balance level, allowing accounts with multiple balances to have separate IBANs per currency. Single Euro Payments Area. A European payment integration initiative that enables euro-denominated credit transfers and direct debits across 36 member countries under unified standards and processing rules. The business of processing card payments on behalf of merchants. An acquirer receives authorisation requests from merchants, forwards them to the issuing bank, and settles funds to the merchant. Paynetics also operates as an acquirer for approved merchant categories. A **Program** defines the configuration under which accounts and cards operate. Programs specify: - supported currencies - account and IBAN generation rules - availability of virtual and physical cards - default card behaviour such as limits, fees, usage controls, and wallet enablement Each account is created under a specific program and references it via a **program code**, which is provided during **partner onboarding**. Programs establish default behaviour at both account level and card level. These defaults can be refined later through API configuration where applicable. An **Account** is a payment or e-money account used to hold funds and execute transactions. Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised. Common account purposes include: - executing card payments and transfers - holding settlement funds - pre-funding services such as OCT An account acts as a container for balances rather than holding funds directly. The business of issuing payment cards to consumers. An issuer approves or declines card transactions in real time and is liable for cardholder credit risk. Paynetics acts as issuer for its partners' card programmes. A **Partner** is the entity that integrates Paynetics’ services and offers them to end customers. Partners operate within their own instance and manage users, merchants, applications, and programs. They define fees, user flows, and configurations within the limits of their contractual agreement and may be responsible for KYC or KYB processing. The partner is the primary integrator and owner of the end-to-end solution built on Paynetics. A **Card** is a payment instrument linked to an account or a virtual account. Cards can be issued as virtual or physical and can be configured for consumer or business use. Each card is associated with a single account and uses the balance of that account for transactions. Card behaviour, including limits, fees, usage permissions, and wallet enablement, is defined by the program and card-level configuration. Original Credit Transaction. A card scheme push-payment mechanism supported on both Visa and Mastercard that credits funds directly to a recipient's card account. The debit side is funded from the sender's settlement or e-money account; the card network routes the credit message to the recipient's issuer. On Visa, OCT underpins Visa Direct; on Mastercard, it underpins the push-payment side of Mastercard Send. Common use cases include marketplace payouts, gambling winnings, insurance disbursements, loan credits, and remittances. Know Your Customer. The regulatory and risk-management process of verifying the identity of individual customers before onboarding them to a financial service. KYC obligations fall on the entity holding the customer relationship. An **Instance** is a logically separated environment within the Paynetics platform. Each partner operates within a dedicated instance. An instance contains all configuration and data related to that partner, including programs, users, merchants, accounts, cards, and transactions. API credentials issued to a partner are always associated with a specific instance. During **partner onboarding**, Paynetics provisions: - a **Sandbox instance** for implementation and testing - a **Production instance** for live operation once partner onboarding is completed and the solution is validated All objects created within the platform belong to exactly one instance. One-Time Password. A single-use numeric or alphanumeric code delivered to a cardholder—typically via SMS—as one factor in a Strong Customer Authentication flow. OTPs are time-limited and invalidated after a single use. Strong Customer Authentication. A regulatory requirement under PSD2 mandating that electronic payments are authenticated using at least two independent factors: something the user knows, something the user has, and something the user is. SCA is enforced at checkout via 3DS for card payments. Payment Services Directive 2. The EU legislative framework governing payment services across the European Economic Area, introducing open banking requirements, Strong Customer Authentication, and increased consumer protections. Anti-Money Laundering. A set of laws, regulations, and procedures designed to detect and prevent criminals from disguising illegally obtained funds as legitimate income. Financial institutions must maintain AML programmes including transaction monitoring, suspicious-activity reporting, and sanctions screening. An arrangement in which Paynetics, as a Principal Member of a card scheme, extends its BIN to a Programme Manager's card programmes. The Programme Manager runs the cardholder ledger and authorisation logic; Paynetics holds the regulatory and scheme relationship. The partner entity that, under a BIN Sponsorship arrangement, runs the cardholder ledger, controls authorisation logic, manages the end-customer relationship, and is responsible for fraud monitoring and AML obligations for its programme.