Scope your testing

What to send

• Product and segment. Say what the product does and which segment it belongs to. The segment shows where a defect costs money, for example interest accrual in lending or settlement in payment acquiring.
• Money flows and integrations. List where money enters and leaves the product: card processors, bank rails such as ACH or SEPA, ledgers, partner bank APIs, and webhooks. Each integration adds failure paths, such as a timeout followed by a retry that posts a payment twice.
• Standards that need evidence. Name the standards an auditor, assessor, or partner bank will review, such as PCI DSS, SOC 2, DORA, or PSD2 strong customer authentication.
• Release cadence. Say how often you release and how long regression takes today. We use this to plan which regression tests run in your CI on each release.
• Next audit or launch date. Give the date the evidence must be ready, such as a PCI DSS assessment, a partner bank review, or a launch in a new market.

Leave out credentials, code, and customer data. The security page describes how we handle cardholder and account data, test environments, engineer access, and contract terms: read before the first call.

What happens next

We reply with a proposed test scope. The scope lists the flows, integrations, and environments to test, the standards we verify against, and the deliverables you receive. For an audit, the deliverables include a requirement-to-test traceability matrix and a test evidence pack per audit scope, as described in audit and certification test evidence.

We sign an NDA before you share architecture documents, code, or environment access. We sign a DPA when the tests touch personal data.