generated: '2026-08-26' method: searched source: >- openapi/*.yml, https://developerhub.ppro.com/global-api/docs/webhooks, https://developerhub.ppro.com/global-api/reference/data-standards, https://developerhub.ppro.com/global-api/reference/api-idempotency, https://developerhub.ppro.com/global-api/reference/error-representation, https://developerhub.ppro.com/.well-known/api-catalog, https://trust.ppro.com/ api: PPRO Global API standards: - id: openapi-3.1 conforms: true evidence: >- All eleven published documents declare openapi 3.1.0 and parse cleanly; the webhook document uses the 3.1 top-level webhooks object for 30 event definitions. - id: cloudevents-1.0.2 conforms: true evidence: >- "all PPRO webhooks follow the CloudEvents 1.0.2 specification" — webhooks guide. The webhook request bodies in openapi/ppro-webhooks-openapi.yml carry specversion (example 1.0.2), source, datacontenttype, id, type, subject, time and data, which is the CloudEvents structured JSON envelope. - id: rfc9727-api-catalog conforms: true evidence: >- https://developerhub.ppro.com/.well-known/api-catalog returns application/linkset+json (HTTP 200) with anchor / service-desc / service-doc members, and the global-api sub-catalog names a service-desc of type application/vnd.oai.openapi+json for every one of the eleven specifications. - id: idempotency conforms: true evidence: >- Request-Idempotency-Key on POST and PATCH, UUIDv4 keys, 24-hour retention, Request-Idempotency response header on replay, 409 on in-flight or body-mismatch replay. 47 declared 409 responses across the specs. Note this is PPRO's own header name, not the IETF draft Idempotency-Key. standard_header: false standard_header_note: The IETF idempotency draft uses Idempotency-Key; PPRO uses Request-Idempotency-Key. - id: iso-8601 conforms: true evidence: All date-time fields are YYYY-MM-DDTHH:mm:ss.sssZ in UTC — data standards page. - id: iso-4217 conforms: true evidence: >- Currency codes are ISO 4217 three-letter codes and amounts are integers in the currency's ISO 4217 minor unit — data standards page, and the MoneyRequest schema in the specs. - id: rfc9457 conforms: false evidence: >- No application/problem+json anywhere in the eleven specs. Errors use PPRO's own {status, failureMessage, timestamp} envelope over application/json. - id: rfc6750-bearer conforms: true evidence: >- securitySchemes bearer_token (type http, scheme bearer) in the payment charges, instruments, agreements and sessions specs; the authentication reference documents Authorization Bearer as the only mechanism. - id: oauth2 conforms: false evidence: >- No oauth2 securityScheme in any spec, and /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource return 404 on api.eu.ppro.com and mcp.eu.ppro.com. API-key bearer tokens only; there is consequently no OAuth scope surface, which is why no scopes/ artifact exists. - id: oidc conforms: false evidence: /.well-known/openid-configuration returns 404 on every probed host. - id: rfc9116-security-txt conforms: false evidence: >- No /.well-known/security.txt on developerhub.ppro.com (SPA shell), api.eu.ppro.com (404), api.sandbox.eu.ppro.com (404) or mcp.eu.ppro.com (404); www.ppro.com answers with a Cloudflare bot interstitial so it could not be read. - id: mcp-2025-06-18 conforms: true evidence: >- https://mcp.eu.ppro.com answered an anonymous initialize with protocolVersion 2025-06-18, serverInfo global-api-mcp 1.0.0, and streamable-HTTP session semantics (mcp-session-id header); tools/list returned 28 tools with full JSON Schema inputs. - id: json-schema conforms: true evidence: OpenAPI 3.1 schemas are JSON Schema 2020-12 dialect; MCP tool inputSchema objects are JSON Schema. - id: rate-limit-headers conforms: partial evidence: >- PPRO returns X-RateLimit-Remaining, X-RateLimit-Requested-Tokens, X-RateLimit-Burst-Capacity and X-RateLimit-Replenish-Rate. These are the legacy X- prefixed style, not the IETF RateLimit / RateLimit-Policy fields, and no Retry-After is documented on 429. - id: hmac-webhook-signing conforms: true evidence: >- PPRO-Signature header, t=,s=, digest sha256(t + "." + rawPayload) keyed with a pre-shared secret. The older non-HMAC Webhook-Signature scheme is deprecated for new customers. domain_standards: - id: pci-dss conforms: unstated evidence: >- PPRO does not name a PCI DSS level anywhere in the public developer hub. The only PCI language published is a SCOPE statement about the integrator: the Drop-in Checkout holds card number and CVV in PPRO-hosted iframes "so your integration stays out of PCI scope". That is an architectural claim about the merchant, not a certification claim about PPRO, and it is recorded as such rather than upgraded. contract_location: https://developerhub.ppro.com/global-api/docs/drop-in-checkout - id: sepa-direct-debit conforms: true evidence: >- SEPA Direct Debit is implemented as a first-class payment method with mandate semantics — SEPA Direct Debit, Managed Mandate and their recurring variants each have their own documented flow, and the instrument schemas carry a Debit Mandate Id on the bank-account instrument. contract_location: openapi/ppro-payment-agreements-openapi.yml (BankAccountInstrumentDetailsRequest), https://developerhub.ppro.com/global-api/docs/sepa-direct-debit - id: emv-3ds conforms: true evidence: >- EXTERNAL_3DS is a published authentication flow and the webhook/charge schemas declare ThreeDsAuthenticationMethodRequest and ThreeDsAuthenticationMethodDetailsRequest. contract_location: openapi/ppro-webhooks-openapi.yml (ThreeDsAuthenticationMethodRequest), https://developerhub.ppro.com/global-api/docs/external_3ds - id: card-network-tokenisation conforms: true evidence: >- CardNetworkTokenInstrumentDetailsRequest / CardNetworkTokenRequest schemas, plus the Network Transaction Identifier and Mastercard Transaction Link Identifier (TLID, 22-character scheme identifier linking CIT to subsequent MITs) features. contract_location: openapi/ppro-payment-agreements-openapi.yml, https://developerhub.ppro.com/global-api/docs/network-tokens - id: open-banking-payments conforms: partial evidence: >- Pay By Bank is documented as an Open Banking Payments method (added April 2026), and PPRO operates regulated entities in the UK and EU. No PSD2/OBIE/Berlin Group API conformance is claimed — PPRO is the consumer of those rails, and exposes its own proprietary contract to merchants rather than an OBIE-shaped one. contract_location: https://developerhub.ppro.com/global-api/docs/paybybank - id: iso-20022 conforms: false evidence: >- No ISO 20022 message types, no pain./pacs./camt. shapes anywhere in the eleven specs. PPRO's contract is a REST/JSON abstraction over the rails, not a financial-messaging surface. compliance_programs: trust_center: present: true url: https://trust.ppro.com/ vendor: Vanta http_status: 200 title: PPRO Trust Center certifications_readable: false note: >- The trust center exists and returns 200, but the report body is rendered client-side by Vanta and the underlying API returns 401 to an anonymous caller, so NO certification could be read. No SOC 2, ISO 27001 or PCI DSS attestation is asserted here because none was verified. This is why no Compliance pointer is wired in apis.yml — a TrustCenter pointer records the surface that was verified, and nothing more. regulatory: note: >- PPRO's privacy notice names PPRO Financial Ltd and PPRO Payment Services S.A. with regulatory registration numbers, and its data-protection terms reference GDPR, the UK Data Protection Act 2018 and the CPRA. These are corporate/legal facts read from the legal pages, not API-contract conformance, and are recorded here for context only. source: https://www.ppro.com/legal/privacy-notice/