Building Payment Processing: When Your AI Agent Handles Real Money

A duplicate charge happened on day three. A traveler booked a flight, the confirmation was slow, she tapped the button again, and two charges appeared on her card. It was a race condition in our idempotency layer where the first request had not yet written to the booking attempt table when the second request arrived. Both requests passed the duplicate check, both created payment intents, and both charged the card.

We fixed it within hours and refunded the duplicate immediately. But the incident shaped our entire approach to payment processing. When your AI agent handles real money, every edge case is a real financial impact on a real person.

Three-layer idempotency

After the duplicate charge incident, we implemented a three-layer system that makes double-booking architecturally impossible.

The first layer is the booking attempt table. Before any payment processing begins, the system creates a booking attempt record with a unique idempotency key. If a second request arrives with the same booking intent, it finds the existing attempt and returns the result of the first request instead of creating a new one.

The second layer is payment processor idempotency. Every payment intent is created with an idempotency key that the payment processor enforces. Even if our application layer somehow allows a duplicate through, the processor will recognize the key and return the original result.

The third layer is the travel data provider confirmation. The booking is only considered complete when the provider confirms it. If somehow both previous layers fail and two booking requests reach the provider, the provider's own duplicate detection prevents a double booking.

Each layer is independent. Any single layer failing does not compromise the protection because the other two layers catch the duplicate. This defense-in-depth approach is more expensive to build and maintain than a single-layer solution, but the cost of a duplicate booking in money, trust, and support time vastly exceeds the engineering investment.

The AI-to-payment handoff

When the agent proposes a booking, there is a critical handoff from AI reasoning to financial transaction. The agent found flights, the traveler selected one, and now real money needs to move. This handoff requires explicit human confirmation.

The agent presents the booking details: flight itinerary, total price with breakdown, cancellation policy, and traveler information verification. The traveler reviews everything and explicitly clicks "confirm booking." Only then does the payment flow begin.

The payment sheet collects card information securely. We never store card data on our servers. The payment processor handles card storage, PCI compliance, and 3D Secure verification when required. Our system creates the payment intent, passes it to the processor, and waits for confirmation.

Testing payments

Our payment test suite runs against real payment processor test modes. Not mocks. Real test-mode endpoints with test card numbers that simulate various scenarios: successful payment, declined card, 3D Secure challenge, timeout, and network error.

Each test verifies the full flow from booking attempt creation through payment processing to provider confirmation. The idempotency system is tested by deliberately sending duplicate requests and verifying that only one charge results. The refund flow is tested by booking, then cancelling, and verifying the refund processes correctly.

Payment endpoints are rate-limited to 10 requests per minute per user. Booking endpoints are limited to 5 attempts per hour. These limits prevent both abuse and accidental duplicates from aggressive client-side retry logic.

Refund processing

When a booking is cancelled, money flows backward through the same layers. The provider cancellation is confirmed. The payment refund is initiated. The booking attempt is marked as refunded. The traveler receives confirmation of the refund with an estimated timeline for the funds to appear.

Refunds are more complex than charges because of timing. A refund initiated today may not appear on the traveler's statement for several business days. The agent communicates this clearly to avoid the anxiety of "I cancelled but the charge is still showing."

Payment processing is where the consequences of bugs are most direct and most visible. A broken search result is frustrating. A duplicate charge is a crisis. We invest disproportionate engineering effort in payment reliability because the trust cost of payment errors is disproportionate to their technical complexity.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.