Services & institutional customers
Sections ↑PPRO connects payments companies to local payment methods whose consumer recognition and settlement conventions differ by country. A card, a European account-to-account transfer, a Brazilian Pix transfer and a digital wallet should not be presented as interchangeable user journeys merely because all are available through the PPRO catalogue.[1]
The Global API is designed to standardise the integration around payment authentication flows rather than embed payment-method-specific business logic everywhere. This is useful for a broker cashier seeking a wider regional funding mix, but it does not establish that the broker’s regulated activity or account is approved for each method.[2]
PPRO’s transaction model separates payment-charge processing from eventual receipt of funds and refund outflow. That is commercially significant where a brokerage account might display a successful deposit before the payment provider receives settlement from the local scheme.[4]
Local payment methods are different payment journeys
| Method family | Customer experience | Operational distinction |
|---|---|---|
| Account-to-account | Payment initiated from a bank account. | Authentication and bank/scheme confirmation differ by method.Source 1 |
| Digital wallet | Payment approved through a wallet relationship. | Refund eligibility and wallet state matter.Source 1 |
| Local cards | Card-based checkout on the enabled scheme. | Card rules differ from bank-transfer rules.Source 1 |
| Regional real-time methods | Country-specific flows such as Pix. | A catalogue listing does not establish merchant underwriting approval.Source 1 |
Platforms & integrations
Sections ↑The developer hub distinguishes sandbox and live API hosts and credentials. Calls use bearer keys and some methods need merchant identifiers. An application should never put a production secret in browser code or copy an example sandbox key into production configuration.[3]
Global API connection model
| Component | Published design |
|---|---|
| REST API | Standardised payment integration.Source 2 |
| Authentication flows | Methods are organised around supported customer-authentication journeys.Source 2 |
| Notifications | Asynchronous changes need to be incorporated into the merchant’s records.Source 8 |
| Method configuration | Enabled methods and merchant identifiers remain account-specific.Source 3 |
Sandbox and live authentication
| Environment | Endpoint or credential rule |
|---|---|
| Sandbox | api.sandbox.eu.ppro.com with sandbox credentials.Source 3 |
| Live | api.eu.ppro.com with live credentials.Source 3 |
| Authentication | Bearer API keys.Source 3 |
| Credential separation | Test credentials do not establish live processing access.Source 3 |
Capture funds states
| State | Documented meaning |
|---|---|
| CAPTURE_FUNDS_NOT_EXPECTED | Processing-only flow: PPRO does not expect funds.Source 4 |
| CAPTURE_FUNDS_WAITING | Awaiting scheme settlement.Source 4 |
| CAPTURE_FUNDS_RECEIVED | PPRO has received the funds.Source 4 |
| CAPTURE_FUNDS_MISSING | Expected receipt did not occur within the expected time.Source 4 |
Refund funds states
| State | Documented meaning |
|---|---|
| REFUND_FUNDS_NOT_EXPECTED | Processing-only refund flow.Source 4 |
| REFUND_FUNDS_WAITING | Awaiting confirmation of refund outflow.Source 4 |
| REFUND_FUNDS_SENT | Scheme confirms funds are on the way; not proof the consumer has received them.Source 4 |
| REFUND_FUNDS_REJECTED | Refund failed, for example because the destination is closed or rejects it.Source 4 |
Pricing & commercial terms
Sections ↑PPRO does not publish a universal all-in payments tariff suitable for every country, payment method and financial-services merchant. The applicable agreement defines the processing services and incorporates schedules and settlement arrangements. Economic comparisons must separate method costs, currency conversion, processing, refund and settlement timing.[5]
Published availability and checkout characteristics do not show whether a particular merchant is accepted for CFDs, investment services or crypto. The provider’s underwriting and scheme rules may restrict a method despite its appearance in the public directory.[1]
Payment-service scope in the commercial agreement
| Component | Distinction |
|---|---|
| Processing | Forwarding and handling transactions.Source 5 |
| Receipt and settlement | Receiving scheme funds and remitting under the agreement.Source 5 |
| Method coverage | Countries and enabled methods depend on the accepted relationship.Source 1 |
| Refund handling | Method capabilities and exception outcomes affect the operational cost.Source 4 |
Published ancillary fees — GTC v1.8
Implementation & delivery
Sections ↑A rejected refund needs a different recovery path
| Stage | Action or consequence |
|---|---|
| Rejected destination | A closed bank account, card or wallet can cause rejection.Source 4 |
| Returned value | Funds return to the merchant.Source 4 |
| Customer reimbursement | The merchant must arrange another refund route outside PPRO.Source 4 |
| Reconciliation | Identify the failed refund before issuing an alternative payment to avoid duplicate reimbursement.Source 4 |
Cashier events and cash availability
| Event | What it establishes | What remains separate |
|---|---|---|
| Shopper return | The browser returned from an authentication journey. | Final processing outcome.Source 2 |
| Charge capture | The payment charge reached its captured state. | PPRO’s receipt of scheme funds.Source 4 |
| Funds received | PPRO received the funds. | Remittance to the contractual partner.Source 4Source 5 |
| Partner settlement | Contractual settlement was made to the partner. | Broker ledger reconciliation and account availability.Source 5 |
Support & contacts
Sections ↑PPRO’s public contact page routes business and partner enquiries, but expressly tells shoppers to contact the merchant or their bank about refunds. A brokerage customer complaint should therefore not be redirected to PPRO as if PPRO operated the brokerage’s customer account.[7]
Published contact and documentation routes
Scope Official route for PSP or institutional payment onboarding.
Scope Implementation guides, sandbox, API and webhook patterns.
Scope Identify the operator and permission scope for a contractual relationship.
Who handles the enquiry?
| Issue | Published route |
|---|---|
| Merchant refund complaint | Shopper contacts the merchant or their bank.Source 7 |
| PSP or business partnership | PPRO’s business contact channel.Source 7 |
| Integration questions | Global API developer hub and contracted support route.Source 2 |
| Entity/permission scope | Published entity directory plus the signed service agreement.Source 6Source 5 |
Gateway SLA in the same terms
| Item | Scope |
|---|---|
| Availability | 99.95% per calendar year; maintenance included.Source 5 |
| Exclusions | Banks, schemes and supply-chain connectivity outside PPRO control.Source 5 |
| Routine support | 08:00–17:00 CET weekdays, excluding German holidays.Source 5 |
| Critical failures | Out-of-hours emergency email service.Source 5 |
Permissions & service scope
Sections ↑PPRO’s entity directory names UK PPRO Financial Ltd as an FCA-authorised electronic money institution with FRN 900029 and identifies Luxembourg PPRO Payment Services S.A. as a CSSF-authorised payment institution. Those are the provider’s published entity descriptions; they do not create one permission automatically covering every business in the group.[6]
Under its payment-services agreement PPRO can forward transactions, receive settlement funds and remit them to a contractual partner. The merchant or PSP retains responsibilities defined by its own agreements, including customer communications, merchant settlement and local legal obligations. A technology connection is not blanket authorisation for a brokerage business.[5]
Published PPRO legal entities
| Entity | Published role or identifier |
|---|---|
| PPRO Financial Ltd | UK electronic-money institution; provider publishes FCA FRN 900029.Source 6 |
| PPRO Payment Services S.A. | Luxembourg payment institution; provider publishes CSSF identifier Z00000022.Source 6 |
| PPRO Holding GmbH | Group holding identity; not a substitute for the operating entity in a processing agreement.Source 6 |
GTC v1.8 excludes consumers, charities and micro-enterprises as contractual partners. Its Girolink appendix lists CFD/forex and retail investment under a “Permitted Industries” heading, while clause 4.3 prohibits using that onboarding API for the listed categories. Obtain written clarification; the contradictory wording is not approval for a broker. The prohibited-industries list separately includes binary options and wealth management.[5]
Operator & evidence
Sections ↑Group and customer relationship
| Item | Published scope |
|---|---|
| PPRO Holding GmbH | Wider group identity.Source 6 |
| Operating agreement | The named PPRO entity supplies the selected payment services.Source 6Source 5 |
| Shopper relationship | A shopper can see PPRO on a statement without being a direct PPRO customer.Source 7 |
| Refund communication | The merchant or shopper’s bank remains the first contact for consumer refund questions.Source 7 |
- Operator
- PPRO Holding GmbH group; services by PPRO Financial Ltd, PPRO Payment Services S.A. and other listed entities
- Service scope
- Payments infrastructure connecting payment-service providers and merchant partners to local payment methods, gateways, authentication flows, settlement and payment data through entity-specific arrangements.
- Customer types
- Payment service providers; Merchant acquirers; Payment platforms; Online marketplaces; Eligible merchants; Financial-services merchants
- Delivery
- API; SaaS; Managed service
- Pricing publication
- Public and quoted pricing
- Platforms
- PPRO Global API; PPRO Local Payments; PPRO Dashboard; PPRO Drop-In Checkout
- Integrations
- REST APIs; Webhook notifications; Sandbox/test keys; Card and local payment schemes; Payments status APIs
- Implementation
- PSP or merchant contracting and onboarding precede live credentials; method-specific availability, consumer authentication, funds status, webhooks, refunds and bank settlement require reconciliation.
- Support
- GTC v1.8 publishes gateway-specific availability and support terms; business contact and developer hub serve distinct needs. Method and bank/scheme dependencies have separate boundaries.
- Permissions and regulatory scope
- PPRO group includes UK FCA-authorised electronic-money and Luxembourg CSSF-authorised payment entities; their scope differs by country and service. PPRO is not the merchant and normally does not handle shoppers’ refund requests directly.
Provider metadata checked 26 Oct 2026Source 1Source 2Source 3Source 4Source 5Source 6Source 7Source 8
Sources & further reading
- PPRO available local payment methods and regions PPRO · Accessed 22 Oct 2026
- PPRO Global API developer onboarding PPRO · Accessed 22 Oct 2026
- PPRO API credentials and sandbox/live environments PPRO · Accessed 22 Oct 2026
- PPRO fund statuses, refund exceptions and webhooks PPRO · Accessed 22 Oct 2026
- Payment Services Agreement GTC v1.8, updated 30 September 2026 PPRO · Accessed 26 Oct 2026
- PPRO current group entities and regulatory descriptions PPRO · Accessed 22 Oct 2026
- PPRO contact and consumer-refund guidance PPRO · Accessed 22 Oct 2026
- PPRO developer resources and standard payment flows PPRO · Accessed 22 Oct 2026
This profile reports dated public information, including provider-published services and terms. It does not independently test or guarantee service delivery, integrations or performance. Inclusion is not an endorsement. Permissions and protections apply only to the named legal entity, service and client category; check the current official records and your contract.