Polling or waiting for a notice
Confirming a SPEI payment has two paths. The first is polling: your system asks periodically whether the payment has settled, with a call to the validation API. The second is waiting for a notice: a webhook, a notification the service sends to your own URL as soon as there's a verdict.
Polling is simpler to build, but it costs calls and takes as long as the interval you choose. A webhook arrives as soon as there's news, but it requires your server to be ready to receive it and respond.
When the notice doesn't arrive
A webhook can fail to arrive: your server was down, the network failed, or your firewall blocked it without you noticing. The standard pattern is for the sender to retry several times, spacing out each attempt, and for the receiver to confirm with a successful HTTP response once it processed it.
If your server takes too long to respond, the sender may read that as a failure and retry more than it should. Process fast and confirm receipt before doing heavy work with the event.
ImportantIf your server can't receive notices yet (it's behind a firewall, or you don't have a public URL), polling is still a valid option: it's slower, but it doesn't depend on someone else finding you.
With VerikoWebhooks retry at growing intervals when your server doesn't respond, and you can send yourself a test event before going to production, without waiting for a real payment.
Don't process a payment twice
If you poll and also get a webhook, or if a webhook retries, your system may see the same payment more than once. Without a way to recognize "I already processed this", the risk is a duplicate charge or a duplicate delivery.
The standard mechanism is an idempotency header: a unique identifier you generate per operation, which the service uses to recognize a repeated request and return the same result without repeating the effect.
NoteYou generate the idempotency identifier, not the service: use one per business operation (an order, a charge), not one per network attempt.
How Veriko does it
Veriko offers both paths: you can look up a validation by its identifier whenever you want, or subscribe a webhook that notifies you as soon as Banxico responds. Both deliver the same verdict.
Webhooks are signed, so you can confirm the notice is ours and not someone else's; if your server doesn't respond, they retry on their own; and every request accepts an idempotency header, so resending the same operation by mistake doesn't process it twice.
| What you need | By hand, without these patterns | With Veriko |
|---|---|---|
| Data | Manual polling, written and maintained by you | API lookup or webhook, your choice |
| Hours | Whenever your polling runs | Any time, with automatic retries |
| Volume | One payment at a time, if you write it yourself | Hundreds of payments by webhook or batch |
| Result | Whatever code you define to read the response | Structured, signed verdict, with retries and idempotency |
| Log | Whatever you build | Delivery history for every webhook, exportable |
If you're building these patterns yourself, there's a free plan that never expires to try them before deciding. The pricing page compares the plans.
Frequently asked questions
What is a webhook, in one sentence?
A notification a service sends to your server when something changes, instead of you having to ask.
Is it better to poll or use a webhook?
It depends on your volume. With few payments, polling is simpler to build; with many, a webhook saves calls and time.
What happens if my server doesn't respond to a webhook?
The sender reads it as a failure and retries later. If your server takes long to come back up, you can miss notices between retries.
How many times does a webhook retry before giving up?
It depends on each service; the common pattern is several attempts with growing gaps, then stopping. Check the delivery history to know if a notice was lost.
What is idempotency and why does it matter for payments?
It's the guarantee that repeating the same operation doesn't repeat its effect. In payments it matters because a network retry shouldn't turn into a duplicate charge.
How do I know a webhook is authentic?
A serious webhook is signed: the sender includes a signature computed with a secret key only you and it know, and your server verifies it before trusting the content.
Can I use only polling, with no webhooks?
Yes. Polling always works and doesn't require a server with a public URL; it just costs more calls and responds with the delay of your own interval.