Lesson 131 Implementation: Introducing the External Provider Manager
In the previous lessons, the Escrow API client was refactored into a reusable HTTP client capable of communicating with Escrow.com in Simulation, Sandbox, and Production environments. While this significantly improved the networking layer, the rest of the plugin still interacted directly with the Escrow client.
This lesson introduces an important architectural improvement: the External Provider Manager.
Rather than allowing business logic to communicate directly with a specific payment provider, all external transaction providers are now accessed through a common manager. Although Escrow.com is currently the only supported provider, this abstraction makes the plugin easier to maintain and allows additional providers to be introduced in the future without affecting the transaction workflow.
Why this refactoring was needed
Prior to this lesson, various parts of the plugin were aware of the Escrow API client itself. That meant changing providers or supporting multiple providers would require modifications throughout the codebase.
The new architecture centralizes that responsibility.
Instead of:
Transaction Manager
│
▼
Escrow API Client
the flow now becomes:
Transaction Manager
│
▼
External Provider Manager
│
▼
Escrow API Client
The Transaction Manager no longer needs to know how Escrow transactions are created. It simply requests that an external transaction be created using the configured provider.
What was implemented
Lesson 131 introduces the Flipnzee_External_Provider_Manager class as the single entry point for external transaction providers.
The manager now:
- Accepts a provider identifier.
- Validates the requested provider.
- Creates an Escrow API client when required.
- Converts internal transaction data into an Escrow-compatible payload.
- Returns a standardized response to the calling code.
This keeps provider-specific logic isolated from the rest of the plugin.
Escrow payload builder
A dedicated payload builder was added to translate Flipnzee transaction data into the format expected by the Escrow API client.
Typical information included in the payload includes:
- Transaction title
- Description
- Amount
- Currency
- Buyer email
- Seller email
Keeping this translation in one place makes future API changes much easier to accommodate.
Standardized provider responses
The Provider Manager also ensures callers always receive a consistent response structure.
Whether the request succeeds or fails, the calling code receives a predictable array describing:
- Success or failure
- Message
- Provider response
This avoids provider-specific handling throughout the plugin.
Benefits
This refactoring provides several long-term advantages.
Separation of responsibilities
The Transaction Manager no longer performs provider-specific work.
Improved maintainability
Changes to Escrow integration are now isolated within the provider layer.
Easier testing
Simulation Mode, Sandbox, and Production all continue to function without requiring changes elsewhere in the plugin.
Future extensibility
Supporting additional transaction providers becomes significantly easier because the Transaction Manager communicates only with the Provider Manager rather than individual provider implementations.
Potential future providers could include:
- Escrow.com
- Trustap
- Stripe Connect
- Manual escrow workflows
- Additional marketplace services
Current status
At the end of Lesson 131, the overall architecture has matured considerably.
The plugin now consists of:
- Transaction Manager
- External Provider Manager
- Escrow Provider
- Refactored Escrow API Client
- Simulation, Sandbox, and Production environments
While additional work remains before production-ready Escrow integration is complete, the major architectural foundation is now in place.
Next lesson
Lesson 132 will focus on standardizing the transaction payload shared between the Transaction Manager, External Provider Manager, and Escrow API Client. Establishing a single canonical payload will simplify debugging, eliminate duplicated mapping logic, and prepare the integration for reliable end-to-end transaction processing.