Developer tools · Payment testing · 2026
Payment Emulator Lab
Test Mercado Pago, Stripe and PayPal integrations in a controlled environment. Reproduce payment failures, validate refunds and verify webhooks before launch, without real money or dependence on a provider sandbox.
Build payment integrations with confidence before they reach your customers. Payment Emulator Lab puts selected Mercado Pago, Stripe and PayPal flows under your control so you can catch integration errors early and turn difficult failures into repeatable tests. Check how your checkout handles a declined payment, verify that a retry does not create a duplicate charge, or confirm that a delayed webhook updates an order correctly. Built for development, QA and automated testing, without depending on a provider sandbox. Testing environment only: no real money, cards or provider credentials.
- TypeScript
- NestJS
- Nuxt
- PrimeVue
- PostgreSQL
- MikroORM
- Docker
Project overview
01 · Context
Payment testing under the team’s control
Developers and QA need repeatable outcomes across gateways. This lab isolates integration tests from real funds and external sandbox availability, while retaining state and provider-specific contracts.
02 · Architecture
Provider plugins over a shared core
A NestJS modular monolith owns payments, idempotency, scenarios, tracing and the ledger in PostgreSQL through MikroORM. Nuxt console and checkout apps use their own Nitro servers. A separate worker delivers the transactional outbox through PostgreSQL, MongoDB or Redis/BullMQ transport.
03 · Decisions
Determinism, contracts and inspectable state
Provider-specific behaviour stays in plugins. Versioned JSON scenarios avoid arbitrary code execution; payment state, balanced ledger postings and webhook events commit together. Runtime payment operations never proxy to real gateways.
04 · Outcomes
A reusable integration test environment
The implemented lab combines three gateway plugins, an operator console, buyer checkout, fault scenarios and bilingual public documentation. Teams can reproduce failures and inspect their effects before validating the supported integration against a real provider sandbox.
How developers use it
- 01
Start the lab and create an application
Follow the local or Docker setup guide. In the operator console, create a test application for the chosen gateway and obtain emulator-issued credentials.
- 02
Point your integration at the emulator
Configure your backend or supported SDK to use the emulator API base URL and its test credentials. Keep the provider’s documented routes and request format; use the returned checkout link when the flow needs buyer interaction.
- 03
Choose a reproducible outcome
Assign a scenario to the application or select one per request with X-Emulator-Scenario. Exercise creation, confirmation, capture, cancellation or refunds according to the provider’s supported operations.
- 04
Inspect state and notifications
Check payment transitions, traces and ledger postings. To test your webhook endpoint, explicitly enable outbound delivery and allow its host in your lab configuration, then inspect signatures, attempts and retries.
When this lab is useful
Build a checkout before going live
Test successful and declined payments, buyer approval, manual capture and full or partial refunds within each gateway’s supported scope.
Exercise failure handling
Inject latency, timeouts, HTTP 429 responses or provider errors to check retry policies, loading states and actionable error messages.
Check duplicate-request protection
Repeat a payment request with the same idempotency key and verify replay behaviour; change its payload to test conflict handling instead of creating a second charge.
Validate webhook consumers
Use Mercado Pago scenarios with duplicate, delayed or invalid-signature notifications to test deduplication, signature checks and asynchronous order updates.
Reproduce a payment that finishes later
Simulate a Mercado Pago ticket that is paid or expires, or a Stripe bank transfer that clears. Run timed transitions on demand in automated tests instead of waiting for the wall clock.
Run isolated regression tests
Create expiring applications for CI, pin custom scenario versions and assert payment state, accounting and notifications without sharing credentials or mutable test data across runs.
Scope: selected provider operations, not their complete product catalogues. Stripe Elements and full provider OpenAPI coverage are not emulated. Use the documented fidelity reports to plan subsequent validation against the official provider sandbox.
Architecture
Loading diagram