This set builds vocabulary for event-driven billing integrations and webhook reliability.
0 / 5 completed
1 / 5
At standup, a dev describes an HTTP callback Stripe sends to notify the application whenever a payment event, like a successful charge, occurs. What is this called?
A webhook is an HTTP callback that Stripe sends to a configured endpoint whenever a relevant event occurs, such as a successful charge or subscription update, letting the application react in near real time without repeatedly polling for changes. This push-based model is more efficient than constant polling. Webhooks are the standard way to keep an application's billing state in sync with Stripe.
2 / 5
During a design review, the team wants to verify that an incoming webhook request genuinely originated from Stripe and wasn't spoofed. Which mechanism supports this?
Stripe signs each webhook payload, and the receiving application should verify this signature using its endpoint's signing secret before trusting the event, preventing an attacker from forging fake payment events. Skipping this verification step is a serious security gap. Signature verification is a standard, required practice for any Stripe webhook integration.
3 / 5
In a code review, a dev makes their webhook handler check whether an event's ID has already been processed before applying its effects again. What is this practice called?
Because Stripe can occasionally deliver the same webhook event more than once, a handler should be idempotent, checking whether an event ID was already processed before applying its effects again, to avoid issues like double-crediting an account. This defensive practice accounts for at-least-once delivery guarantees common in webhook systems. Idempotency is essential for correctness in billing-related event handling specifically.
4 / 5
An incident report shows a webhook endpoint was down for several hours, and some payment events were missed entirely. What Stripe mechanism would have limited the impact?
Stripe automatically retries webhook delivery with backoff over an extended period if an endpoint is temporarily unreachable, which limits data loss during brief outages as long as the endpoint recovers within the retry window. Relying on this retry behavior, combined with periodic reconciliation against Stripe's API as a backstop, reduces the impact of transient downtime. Understanding retry behavior is important for reasoning about webhook reliability guarantees.
5 / 5
During a PR review, a teammate asks why the billing logic reacts to Stripe webhooks instead of polling the Stripe API on a schedule for changes. What is the reasoning?
Webhooks push relevant events to the application as they happen, avoiding both the latency of waiting for the next poll cycle and the inefficiency of repeatedly querying for changes that may not have occurred. Polling could work but introduces unnecessary delay and API load compared to an event-driven push model. This tradeoff is why most Stripe integrations rely primarily on webhooks for time-sensitive billing state.