We model real payment, ledger, onboarding and event flows and measure where latency, errors, queue lag and correctness begin to fail, then verify the fix before customers feel it. For payment processors, gateways, wallets, ledgers, embedded finance and fintech SaaS.
One Documented Card-Processing Engagement
All three figures come from one card-processing engagement in 2020. The client is confidential; a comparable reference call is available at the finalist stage.
Card processing, payouts and core systems from published PFLB engagements
A bank with 31.6 million customers moved card processing in-house. ISO 8583 load found a message-queue backlog on one interface, go-live moved three months, and the repeat run passed.
Read full case
Visa and Mastercard processing on a core with 65 million customers: a 24-hour reliability run across 50+ business cases before each of 11 yearly releases, for seven years.
Read full case
A payroll platform for Europe's largest employers: registries of up to 9,000 records, 12 transaction statuses tracked, 43 data generators and 29 emulators for 7 adjacent bank systems.
Read full case
A large bank's customer-profile platform, not a payment switch: 16 application servers, 6 external integrations, a 0.5-second target through the service bus, 15,000 TPS standard and up to 30,000 at peak.
Read full case
How the Engagement Runs
Critical flows, the peak event and its date, dependencies, constraints and your decision deadline, on a 30-minute call within one business day of your request.
Access model, test data, telemetry and the plan for emulating external dependencies. A load test needs no production access.
Transaction mix, arrival rate, bursts, batch windows and pass/fail criteria, derived from your analytics and approved by your team. Test types follow the written scope.
Scripts, data generators and emulators, then a baseline run to prove the package works in your environment.
The agreed load, stress, soak or resilience runs with correlated telemetry, so every bottleneck comes with reproducible evidence.
One re-run of the approved workload after your fix, so the engagement ends with a measured capacity limit and the conditions it holds under.
What a vendor review asks first, answered here so the call can be about your system.
Named engineers in the US, the UK and Iceland, in the test environment you provide, over VPN or a bastion host, under a mutual NDA and an MSA with a security exhibit.
Synthetic data generated for the load profile, or your own data masked before it reaches the test. Card numbers are generated or tokenised.
No, and an engagement does not make us one. The standard engagement is designed to stay outside your cardholder data environment; you and your QSA confirm the final scope.
Tell us about your peak day. A performance engineer replies within one business day, and the call is booked on the next step.
We replace them with emulators. For a bank's processing migration PFLB built an ISO 8583 emulator in-house, plus emulators of adjacent systems over JDBC, SOAP and Oracle AQ, so the test generated card transactions at volume without a single call to a live network. Third-party sandboxes such as Stripe or Plaid are rate-limited and not built for load, so we emulate their responses, including latency and failure modes, and test how your side behaves: retries, idempotency keys, timeouts, and what happens to the ledger when the third party is slow.
No. Load tests run against a prod-like test environment you provide, with synthetic data generated for the load profile or your own data masked with PFLB Data Masking before it reaches the test. Card numbers are generated or tokenised. Read access to your monitoring during the run helps us correlate server-side metrics with each request, but it is optional. What leaves your network is what you agree to: the metrics, logs and report needed to write up the run, under the retention terms in the MSA.
From your own analytics and logs: the transaction mix, arrival rate and think times of a normal day, scaled to the peak you expect and then past it, so you learn where the system degrades, not only whether it survives the target. Batch windows, webhook fan-out and background jobs go into the model, because they are usually where the queue lag comes from. You approve the model before the first run, and the same model is used for the validation re-run.
Apache JMeter and LoadRunner for most fintech systems, Gatling or k6 where your team already lives in those, and the PFLB Platform for cloud load from the regions your users are in, with Grafana, InfluxDB and Telegraf for server-side monitoring. Scripts, data generators, emulator configuration and documentation are delivered to your repository by default, so your team can run them. Pipeline integration, monitoring integration and recurring managed testing are separate lines in the proposal, included or optional as you choose.
PFLB is not a PCI DSS service provider, and an engagement does not make us one. Load tests run against test environments, on synthetic or anonymized data, and our process is built to keep engineers away from live card numbers. That is designed to keep us outside your PCI DSS scope, so in a typical engagement your assessor does not need an attestation from us; your final scope is confirmed by you and your assessor, not by us. Where a project could involve real cardholder data, we flag it and agree the handling before the contract. PFLB holds a SOC 2 Type II report covering Security, Availability and Confidentiality, available under NDA on the security page; SOC 2 is an independent examination rather than a certificate, and PFLB is not ISO 27001 certified.
A fixed proposal follows the discovery call and the environment-readiness review. It states the scope, scenarios, milestones and first-result date; the named PFLB team and the client owners we need; the environment, data and access model; the deliverables and reuse rights; and the price with its assumptions, exclusions and change boundaries. The price depends on the number of critical flows, the environments and workload profiles, the external dependencies and custom emulators, the test types and their duration, monitoring integration, and the validation runs. The discovery call itself happens within one business day of your request.
Yes to both. Two sample reports show the format your engagement would produce, a SAP HANA load testing report and a core banking system report: the tested workload, p50, p95 and p99 per endpoint, throughput, error rate, the load at which each flow degrades, the evidence behind each bottleneck and the fixes in priority order. A redacted report from a comparable payments engagement is shown on the discovery call. A reference call with a customer whose system and scale are comparable to yours is arranged at the finalist stage, once both sides know the engagement is real.
A bank with 31.6 million customers was bringing credit and debit card processing in-house on TranzWare Online and TranzWare CMS. PFLB ran the same test series on the old configuration and on the new architecture: ISO 8583 card transactions from an emulator built in-house, plus emulators of adjacent systems over JDBC, SOAP, Oracle AQ and PL/SQL. A message-queue backlog on the CBA interface degraded every transaction type, and throughput fell below a quarter of the pre-migration baseline. Go-live was postponed by three months, the developer fixed the bottleneck, and the repeated run passed before the system went live.
Because that is where PFLB's published payment-layer evidence is. The areas listed under "What We Can Test" describe scope; what each engagement covers is agreed in the written proposal. This page is about payment and fintech product flows, and banking engagements appear only where the system under test was card processing, payment routing, transaction infrastructure or payouts. Since 2008, 150+ PFLB engineers have run performance testing for 300+ companies. For core banking, lending and branch systems, see Banking and Finance.
