Submission checklist

Why this matters

Every additional round trip between our compliance analysts and your team adds days, not hours, to a request — external parties like card networks and banks also work in batches, and a case that needs "one more document" can lose its place in that batch. Completing this checklist before you open a request is the single most effective thing you can do to shorten turnaround time.

Before you start

1. Confirm the processor origin. Is this a processor built by Pay Engineers, or an external vendor you want connectivity and credential support for? The evidence we need differs significantly between the two.
2. Gather architecture notes. A short description of the payment rails involved (cards, SEPA/SCT, open banking, wallets, crypto rails), the target markets/jurisdictions, and expected transaction volumes helps us size the request correctly the first time.
3. Upload existing certificates or licence evidence. If you already hold a PCI DSS attestation, an e-money or payment institution licence, or a prior card scheme certificate, upload it even if it looks outdated — it tells us what does not need to be redone.
4. Nominate a technical contact. This person will be looped in for sandbox validation and protected connection tests, and should have the ability to update DNS records, firewall allow-lists and application configuration on short notice.
5. List your current environments. Tell us which environments (development, staging, sandbox, production) need credentials, and whether they share infrastructure or are fully isolated — this affects how many parameter sets we generate.

Documents we commonly request

• Corporate registration and beneficial ownership documents (for KYB on the requesting entity).
• Prior PCI DSS Attestation of Compliance (AOC) or Report on Compliance (ROC), if applicable.
• Evidence of an existing licence, authorization or passporting notification.
• A network diagram or short written description of where cardholder data or payment credentials will be stored, processed or transmitted.
• Business continuity / disaster recovery summary, for certificate types that require it.

Technical details we will ask for

• Public IP ranges (egress and, if relevant, ingress) that need to be allow-listed by the processor or scheme.
• The domains and subdomains that will call sandbox and production endpoints, so TLS and DNS checks can be scoped correctly.
• Preferred authentication method if the target processor supports more than one (API key, OAuth2 client credentials, mutual TLS).
• Webhook endpoint URLs, if the integration includes asynchronous notifications.

Common reasons requests stall

• Missing technical contact. Compliance evidence alone is not enough — someone has to actually run the connection tests.
• Ambiguous processor origin. "We think it's one of yours but we're not sure" adds a discovery step that a five-minute check on your side would avoid.
• Incomplete IP ranges. Partial allow-lists mean the protected connection tests fail in ways that look like our error but are actually a configuration gap on the client side.
• Stale documents. Certificates or licence evidence more than 12 months old are usually re-verified anyway, so it's faster to fetch current versions before submitting.

What happens after you submit

Once the checklist above is satisfied and the request is opened, it moves to New request and then Under analysis. If anything is still missing, the status will change to Additional information requested with a specific note — see the FAQ article for a full glossary of statuses. Assuming everything above was prepared correctly, most first-time requests move straight from analysis to delivery without needing that intermediate step.