Mocking Third‑Party Payment Services with Java Instrumentation for Reliable Testing

Overview

The upstream payment business often encounters testing difficulties because payment scenarios require interaction with third‑party services, making simple interface stubbing insufficient. Directly modifying the code or database is complex and costly.

Background

Testing payment flows involves interacting with third‑party services, which cannot be bypassed by simple API calls.

Constructing exceptional scenarios (e.g., WeChat deregistration, bank card cancellation) manually is time‑consuming and unreliable.

Disaster recovery testing requires simulating third‑party service outages (e.g., HTTP 500/502).

Payment reconciliation needs large‑scale third‑party bill downloads, making accuracy hard to guarantee.

Other third‑party dependent business faces similar data‑construction challenges.

Goals

Enable construction of various exceptional scenarios in the early stage, turning hard‑to‑test cases into testable ones.

Reduce deployment cost and integrate with existing platforms in the mid stage.

Lower development effort for business integration later.

Solution Selection

Business Characteristics

Payment center interacts with third‑party services through a unified gateway service.

The gateway loads public keys and communicates with third parties via an HttpClient.

Interception Options

Option 1: Configure host entries on the server to point third‑party payment domains to a mock server.

Pros: Simple configuration, non‑intrusive.

Cons: Most payment requests use HTTPS; mock requires private keys or self‑signed certificates.

Option 2: Use Java instrumentation to replace the original HttpClient with one that ignores certificate verification and performs custom DNS resolution, directing requests to the mock service. See "Java Bytecode Enhancement Techniques" for implementation details.

Pros: Guarantees interception effectiveness, no certificate pairing needed, memory‑level instrumentation is non‑intrusive to source code.

Cons: Requires developer cooperation to identify suitable instrumentation points.

The final choice is Option 2 because host‑based interception is less powerful than code‑level interception.

Implementation

Instrumentation JAR

SSL‑trusting HttpClient for communication with the mock platform.

Custom DNS resolver that maps target domains to the mock platform.

Java agent that replaces the original HttpClient when the tested service starts.

Mock Service

1. Provide interfaces with the same names as third‑party services.

2. Receive requests from the tested service and return responses according to business rules.

3. Support callback capabilities where the mock service actively calls back after receiving specific requests.

4. Simulate exception registration and signature generation for callbacks.

Nginx Configuration

If the mocked third‑party service uses HTTPS, a certificate must be issued via OpenSSL, but the instrumented HttpClient ignores certificate verification, so the mock side does not need to load the certificate.

Integration with Environment Platform

1. Configure mock rules on the mock platform.

2. Enable third‑party mock in the environment platform.

Third‑Party Mock Interaction Sequence Diagram

(Diagram omitted – original source includes an image illustrating the request‑response flow.)

Third‑Party Mock Planning

Make the mock configuration-driven to reduce development effort for business integration.

Instrumentation rules are configurable.

Monitored interfaces are configurable.

Returned information is configurable.