Case study 01 · Card-present payments

Making a terminal-partner integration ready for production.

Connecting a terminal partner is not just an API project. The terminal, payment application, processor path, certification work, sandbox, and team handoffs all have to move together.

Card-presentEMV L3GraphQLPartner integration

RoleTechnical lead

ScopePartner integration · EMV L3 · APIs

TeamsFour internal teams plus external partners

Constraints

The partner integration exposed gaps in APIs that had previously been internal.
EMV L3 certification had to cover multiple processors and regions.
Partner testing was blocked by sandbox test-card controls.
The team had to move quickly without weakening payment or security boundaries.

What I owned

Coordinated scope and delivery across four internal engineering teams and external partners.
Documented 12+ APIs and supported partner integration testing.
Designed and shipped Quick-Chip support in 2 weeks when the partner could not support the full flow.
Coordinated sandbox PAN whitelisting across four services, unblocking testing in 3 days.
Supported EMV L3 certifications across US and UK/EU processor paths.

Outcome

Fiserv and Amex Direct certifications completed one month ahead of schedule.
Partner testing was unblocked without exposing production card data.
The integration moved forward with clearer API ownership and testable boundaries.

What this teaches

Treat terminal integrations as an end-to-end system: device, payment application, processor, APIs, test environment, and certification.
Make the partner-facing contract explicit before implementation spreads assumptions across teams.
Separate sandbox controls from production data paths so urgent testing does not weaken security boundaries.

Standards and ecosystem references

EMVCo: EMV Level 3 Testing ↗PCI SSC: Point-to-Point Encryption ↗

Confidentiality note. This is a sanitized account. Company-internal names, merchant details, ticket IDs, and private implementation data are intentionally omitted.