No Silent Fallbacks in Payment Code
Payment systems fail in ordinary ways. A provider has a short outage. A network call times out. A configuration is missing for one product. In each case, a developer is tempted to write a little rescue: if the main route fails, try a second route. The customer pays, nobody sees an error and everyone moves on.
We do not write those rescues. When a payment route our platform is configured to use is unavailable, the payment stops, the customer sees a clear message and nothing is charged through an unexpected path. This post explains why that rule matters so much to us.
One configured route at a time
Our platform has a shared payment hub that handles the charges customers make to us: plans, add-ons, wallet top-ups and AI credit packages. Each product is configured to use a specific route, and the code reads that configuration for every charge.
If the configured route is the hub and the hub cannot be reached, the honest answer is "this payment cannot be completed right now." Quietly sending the charge directly to a provider instead would create a second, unplanned path, with different records and different rules.
What goes wrong with silent fallbacks
A silent fallback seems helpful in the moment. The trouble shows up later, in places that are hard to untangle:
- Records split. One charge lives in the hub's records, another in the provider's dashboard only. Reports disagree and nobody is sure which is complete.
- Refunds get complicated. A refund needs to go back through the route the money came in on. If the route was chosen silently, support staff may not know which one to use.
- Books drift. Our accounting records are created from verified payment events on the expected path. A charge that skipped that path can be missing from the books entirely.
- Access gets granted wrongly. Paid features turn on only after a verified, signed confirmation arrives. A fallback route may not send that confirmation the same way, leaving the customer charged but locked out, or unlocked without the expected record.
Each of those is far more painful than a short "please try again" message.
Fallbacks hide outages
There is a quieter cost too. When a fallback rescues every failure, the main route can be broken for days without anyone noticing. Errors that should have been alarms become invisible. Failing loudly means problems are reported, investigated and fixed, instead of being papered over until the backup route fails as well.
The same rule for AI features
We apply the same principle to paid AI features. When an AI request goes through our gateway and the gateway fails, the request does not retry through a different provider on a different bill. The failure is reported, the customer is not charged for work that did not happen and an uncertain request is never replayed in a way that could charge twice. You can read more in failing closed.
Customers' own payments follow the rules they chose
Organizations that sell through our platform, such as a church taking donations or a shop selling products, choose how they accept payments in their own payment settings. Every module reads those settings and uses the route the organization chose. No module decides on its own to send a customer's sale somewhere else, and none of them falls back to our company account if the organization's own account has a problem. Their money stays on their rails.
What a good failure looks like
Failing honestly does not have to feel harsh. A good payment failure:
- Tells the customer clearly that nothing was charged, when that is true
- Offers an easy way to try again
- Logs the technical details for our team, not for the customer's screen
- Leaves no half-finished records behind
- Alerts us when failures repeat, so the root cause gets fixed
The principle behind it
Money is where trust is most fragile. A customer who sees a temporary error usually understands. A customer who finds a charge nobody can explain does not. Choosing one recorded path, every time, is how we keep payments explainable from the first click to the final line in the books. It is the same discipline behind Pay by Jag, our payments and bookkeeping product.
Frequently asked questions
What is a payment fallback?
A payment fallback is code that automatically sends a charge through a different provider or route when the main one fails. It can hide outages and split payment records.
What happens if a payment provider is down?
On our platform the payment stops with a clear message and nothing is charged through an unexpected route. The customer can try again when the service is back.
Why not retry a failed payment automatically?
A failed request may have partly succeeded. Retrying blindly can charge twice, so uncertain payments are checked before anything else happens.
Related Posts
Why Card Numbers Never Touch Our Servers
The safest way to protect card numbers is to never hold them. Here is how our checkout forms send card details straight to the payment processor instead.
Every AI Call Is Registered Before It Runs
AI features cost money and touch customer data, so we keep a registry of every one. Here is how a call that is not on the list is refused before anything is spent.
Every Payment Lands in the Books
A payment that never reaches the accounting records creates work and risk later. Here is how our payment flows connect to the books from the very first charge.
Idempotency: Making Sure a Payment Happens Once
Networks retry, people double-click and confirmations arrive twice. Here is how idempotency keeps every payment, credit and renewal from happening more than once.
Audit Trails: Recording Who Changed What
When something changes unexpectedly, the first question is who changed it and when. Here is how audit trails answer that question without becoming a privacy problem.
Comments (0)
No comments yet. Be the first to share your thoughts!