Only a Verified Payment Signal Grants Paid Access
Picture a customer completing a purchase. They enter their card, press pay and land on a thank-you page. It is tempting for software to treat that moment as the end of the story: the customer is back, so the payment must have worked, so turn on the paid features.
That shortcut is one of the most common sources of payment bugs and abuse. In our platform, paid access, subscription renewals and wallet credits change only after a verified, signed confirmation of payment arrives from the payment system. Here is why.
Why the redirect is not proof
When a browser returns from a payment step, all our server knows is that someone loaded a page. The payment might still be processing. It might have failed after a delay. The customer might have closed the payment window and pasted the thank-you address by hand. A crafty user might even guess the address and visit it without paying at all.
None of those cases should unlock anything. If the thank-you page granted access, every one of them would.
What a verified signal is
Payment systems send their own confirmation directly to the merchant's server, separate from the customer's browser. Our platform requires that confirmation to be signed: it carries a cryptographic signature created with a secret that only the payment system and our server share. Before acting on a confirmation, our server recalculates the signature and compares. If it does not match, the message is ignored.
A valid signature proves the message came from the payment system and was not changed on the way. That is what makes it trustworthy enough to act on.
What only a verified signal can do
In our platform, these changes require a verified payment confirmation and nothing else:
- Granting access to a paid plan or add-on
- Extending a subscription to its next period
- Adding value to a prepaid wallet
- Creating a paid invoice and its accounting records
The thank-you page still exists, and it is friendly. It simply reflects the current state, which may say "your payment is being confirmed" for a few seconds until the signal arrives.
Matching the signal to the right order
A valid signal still has to be matched to the right purchase. Each payment carries an identifier created when the payment began. When the confirmation arrives, we find the order by that identifier, check that the amount and customer match and confirm the order has not already been fulfilled. Only then do we grant access or credit.
That last check matters because confirmations can arrive more than once. Networks retry. Matching by identifier and recording that an order was fulfilled means a duplicate confirmation does nothing the second time. You can read more in idempotency for payments.
Off-session charges follow the same rule
Some charges happen while the customer is away, such as an automatic wallet top-up from a saved card when a balance runs low. Even though our server started that charge itself, the wallet is credited only when the verified confirmation arrives. Starting a charge is not the same as completing one.
Failure is handled honestly
If a confirmation never arrives, or arrives saying the payment failed, nothing is unlocked and the customer sees an accurate status. If the payment system that should send confirmations is unavailable, the purchase does not proceed through some other route. We describe that principle in no silent fallbacks in payment code.
Why this matters
Customers deserve to get what they paid for the moment payment is real. Organizations deserve not to give away paid features by accident. Accounting deserves records that match actual money. A single rule, act only on verified signals, serves all three. It is the foundation of our shared payment hub and of Pay by Jag.
Frequently asked questions
What is a payment webhook?
A webhook is a message a payment system sends directly to a merchant's server when something happens, such as a payment succeeding. It does not depend on the customer's browser.
Why does access sometimes take a few seconds after paying?
Access turns on when the verified confirmation arrives from the payment system, which can take a moment after the thank-you page loads.
What if the same confirmation arrives twice?
Each confirmation is matched to its order by identifier, and an order that was already fulfilled is not fulfilled again.
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.
Letting Customers Get Paid Directly With Connected Accounts
When an organization sells through our platform, the money should land in its own account. Here is how connected accounts, platform fees, refunds and disputes work.
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.
Failing Closed: When the Safe Answer Is No
When a check cannot be completed, software has to choose between allowing and refusing. Here is why we design money, access and AI features to refuse until they are sure.
Comments (0)
No comments yet. Be the first to share your thoughts!