TrushexCase study / payments
Payment Gateway Orchestration
A payments business had multiple gateway integrations with inconsistent API contracts, manual fallback behavior, and unstable payment flows. Trushex designed an orchestration layer that gave internal teams one stable payment contract while keeping provider-specific behavior isolated behind adapters.
Challenge
The platform had grown through several provider integrations, each with its own status model, webhook behavior, retry semantics, and operational quirks. Engineers had to remember which provider treated pending, authorized, captured, failed, and reversed states differently, and support teams could not easily explain where a transaction was stuck.
Manual fallback created additional risk. When a gateway degraded, teams had to decide whether to retry, switch provider, wait for a webhook, or manually reconcile the transaction later. That slowed incident response and made every new provider onboarding project feel like a custom integration rather than a repeatable capability.
Solution architecture
Trushex introduced a normalized payment API that separated merchant-facing flows from gateway-specific details. Provider adapters handled request mapping, status translation, webhook normalization, retry behavior, and idempotency concerns, while the orchestration layer owned the business-level payment lifecycle.
The design also created a transaction trace model across internal IDs, provider references, webhook events, and retry attempts. This made payment state easier to inspect without exposing operations teams to provider-specific API details.
Implementation highlights
The delivery focused on durable integration boundaries rather than one-off glue code. Each implementation decision was made to keep provider behavior, operational visibility, and future extension points explicit.
- Designed OpenAPI contracts for payment and webhook endpoints.
- Separated provider adapters from orchestration rules to reduce coupling.
- Added Redis-backed idempotency controls and Kafka event publishing.
- Created clearer logs around provider status changes and webhook handling.
Results
The outcome was presented carefully as operational improvement, not as unverifiable performance claims. The value came from clearer ownership, faster investigation, and lower integration friction.
- Reduced integration maintenance.
- Faster gateway onboarding.
- Improved transaction traceability.
Similar work
Teams with similar integration constraints often start by mapping provider behavior, system ownership, operational signals, and the transaction or data states that need to become explicit.