DEV Community: Martin Pisacreta

Cómo recibo webhooks de Mercado Pago en ASP.NET Core

Martin Pisacreta — Wed, 28 Oct 2026 01:54:54 +0000

Una notificación de pago puede llegar más de una vez. También puede aparecer cuando mi aplicación ya recibió una actualización más reciente. Si cada entrega dispara otra acreditación, un reintento puede convertirse en un problema de dinero y conciliación.

Preparé una muestra propia en ASP.NET Core 8 para explorar ese flujo: autenticar la notificación, consultar el pago y actualizar una orden sin repetir trabajo ante una entrega idéntica. Sus ocho pruebas pasan en Windows sobre .NET 8, con la compilación Release sin advertencias ni errores. La muestra utiliza memoria y una API simulada; todavía no demuestra una integración real con Mercado Pago.

Estos son el recorrido, las comprobaciones y los límites que mantengo visibles antes de adaptar el ejemplo a un negocio.

Separar la notificación del estado del pago

Mi endpoint recibe un identificador, pero no toma el estado del pago ni la orden asociada del cuerpo de la notificación. Esos datos deben venir de una consulta autenticada a la API de pagos.

La interfaz IPaymentsApi devuelve el identificador del pago, la orden local verificada, el estado y la fecha de actualización. El adaptador debe resolver la referencia del proveedor contra mis registros. Una firma correcta no reemplaza esa comprobación de negocio.

La muestra no incluye ese adaptador real. Registra una implementación que devuelve un error y responde 503 ante una notificación autenticada. Para usarla con pagos reales, primero tendría que implementar y validar la consulta con credenciales guardadas fuera del código.

Validar la entrada antes de procesarla

POST /mercadopago/webhook acepta data.id desde la consulta o desde un objeto JSON. Si ambas ubicaciones incluyen el identificador, exige que coincidan exactamente. Una discrepancia produce 400 en lugar de elegir silenciosamente uno de los valores.

También exige un solo encabezado x-request-id y uno x-signature. El procesador interpreta una firma con componentes ts y v1, rechaza componentes desconocidos o repetidos y comprueba que el resumen hexadecimal tenga la longitud esperada.

Son reglas concretas de esta implementación. No presento el ejemplo como compatible con cualquier variante de notificación: esa compatibilidad sigue necesitando pruebas con entregas reales.

Normalizar el identificador dentro del manifiesto

La firma se calcula sobre un manifiesto, no sobre todo el JSON recibido. En esta muestra, el valor de data.id se convierte a minúsculas al construir ese texto. El identificador de solicitud conserva sus mayúsculas y minúsculas.

Este es el primer fragmento de mi archivo Webhooks.cs:

manifest = $"id:{input.PaymentId.ToLowerInvariant()};request-id:{input.RequestId};ts:{timestamp};";
var expected = HMACSHA256.HashData(secret, Encoding.UTF8.GetBytes(manifest));
return CryptographicOperations.FixedTimeEquals(expected, supplied);

El punto y coma final forma parte del manifiesto. Uso UTF-8, HMAC-SHA256 y comparación de los bytes en tiempo constante. El secreto de webhooks es distinto del token utilizado para consultar pagos.

La normalización no modifica el identificador que envío al adaptador ni el que guardo en la orden. El octavo caso usa ABC123XYZ, calcula la firma independientemente con abc123xyz y conserva MixedCaseRequest8 como identificador de solicitud. Así comprueba que solo se normalice el valor destinado al manifiesto.

El procesador también exige que la marca de tiempo esté dentro de una tolerancia configurable, de cinco minutos por defecto hacia el pasado o el futuro. El reloj es inyectable para probar ese comportamiento sin depender de la hora de ejecución.

Reconocer una repetición exacta

Después de autenticar, el procesador adquiere un semáforo y revisa un conjunto de manifiestos procesados. Este segundo fragmento muestra la salida temprana:

if (processed.Contains(manifest))
    return new(200, "duplicate");

Una repetición exacta dentro de la ventana válida recibe 200 sin volver a consultar la API. La autenticación ocurre antes: una entrega vencida recibe 401 aunque su manifiesto haya sido procesado previamente.

Si cambia el identificador de solicitud o la marca de tiempo, cambia la clave y se consulta nuevamente el pago. Eso permite observar actualizaciones posteriores del mismo pago, como el paso de pendiente a aprobado. Deduplicar permanentemente solo por identificador de pago impediría aplicar esa transición.

Cuando el adaptador falla, respondo 503 sin registrar el manifiesto como procesado. De esa manera, el intento fallido no bloquea una entrega posterior.

Evitar que una actualización vieja haga retroceder la orden

Una entrega nueva puede traer una consulta cuyo resultado sea anterior al estado guardado. Comparo la fecha de actualización obtenida de la API, no la hora de llegada del webhook ni la marca de su firma.

El tercer fragmento contiene las reglas de retroceso:

var stale = payment.UpdatedAt < order.UpdatedAt;
var wouldRegress =
    (order.Status == "approved"
        && payment.Status is "pending" or "rejected")
    || (order.Status == "refunded" && payment.Status != "refunded");

Un resultado anterior o una transición prohibida recibe 200 con ignored_stale_or_regressive. La orden conserva su estado. Un resultado actual o posterior puede llevar una aprobación a reembolso; una orden reembolsada no vuelve a otro estado con estas reglas.

La muestra admite un pago por orden. Si aparece otro identificador para una orden ya asociada, responde 409. Es una decisión del ejemplo que habría que revisar para negocios con varios intentos de pago.

Qué cubren las ocho pruebas

Las ocho pruebas pasan en Windows sobre .NET 8, con la compilación Release sin advertencias ni errores.

Los casos cubren pago aprobado, firma incorrecta, firma vencida, notificación duplicada, transición de pendiente a aprobado, pago rechazado, aprobación seguida de un resultado pendiente antiguo y normalización del identificador alfanumérico.

El ejecutor llama directamente al procesador con un reloj fijo y una API falsa que cuenta consultas. El caso duplicado verifica una sola consulta después de dos entregas. Los casos de firma inválida o vencida comprueban que no se consulte la API ni se modifique la orden.

No se inicia un servidor HTTP ni se realizan llamadas externas. Tampoco hay pruebas específicas de reembolsos, concurrencia distribuida o recuperación después de un reinicio.

Qué falta para una acreditación durable

Las órdenes y las claves procesadas viven en memoria. Un reinicio borra ambas, y el conjunto de claves crece sin una política de retención. El semáforo coordina una instancia y mantiene serializadas incluso las consultas al adaptador; no coordina varios procesos.

Además, actualizar un estado no equivale a acreditar dinero una sola vez. El ejemplo no ejecuta una acreditación contable, un envío ni una transferencia. Para incorporar esos efectos necesitaría almacenamiento durable, restricciones únicas y una transacción que vincule la protección contra duplicados con el cambio de negocio. Las acciones externas requieren su propia estrategia de recuperación.

Los tres fragmentos pertenecen a mi muestra propia, sin repositorio público. La considero una base verificable para discutir el flujo, con integración real y persistencia todavía pendientes.

Si necesitas recibir webhooks de Mercado Pago en tu API de ASP.NET Core, escríbeme sobre tu flujo de pagos y los reintentos que necesitas resolver.

How I Protect an ASP.NET Core API with Microsoft Entra ID

Martin Pisacreta — Wed, 28 Oct 2026 01:53:35 +0000

A token can have a valid signature and still belong to another API. A caller can authenticate successfully and still lack permission to write an order. I want those failures to remain separate, both in the implementation and in the HTTP response.

I built entra-id-api-dotnet, a small ASP.NET Core 8 API demonstrating JWT validation and independent scope and role policies. Its 14 integration cases pass in GitHub Actions CI. They exercise the actual JWT middleware with locally signed tokens; they do not establish a working connection to a live Microsoft Entra tenant.

Here is how I set up that boundary and what the tests actually demonstrate.

Start with one tenant and one audience

The application requires two configuration values: Entra:TenantId and Entra:Audience. Startup rejects an invalid or empty tenant GUID and a blank audience. The README specifies the API application's client ID GUID as the audience for v2 access tokens.

I construct the authority from that tenant: https://login.microsoftonline.com/{tenant}/v2.0. This sample uses a single configured issuer. It does not select a tenant from an incoming token or maintain a list of accepted organizations.

The registration instructions request v2 access tokens, expose the delegated scope api.read, and define an application role named Orders.Write. A separate caller registration receives the appropriate permissions and consent. The API validates incoming credentials; it does not need a client secret to perform that validation.

The configuration fields start empty. Environment variables can supply their values, allowing deployment settings to stay outside the source tree.

Validate before trusting claims

Decoding a JWT is useful for inspection, but the decoded payload is not evidence that its claims are trustworthy. I configure JWT bearer authentication before using those claims in authorization policies.

This excerpt from Program.cs shows the validation parameters:

ValidateIssuer = true,
ValidIssuer = issuer,
ValidateAudience = true,
ValidAudience = audience,
ValidateIssuerSigningKey = true,
RequireSignedTokens = true,
ValidateLifetime = true,
RequireExpirationTime = true,
ClockSkew = TimeSpan.FromSeconds(30),
ValidAlgorithms = new[] { SecurityAlgorithms.RsaSha256 },
NameClaimType = "name",
RoleClaimType = "roles"

The surrounding configuration requires HTTPS metadata and disables inbound claim mapping. Production authentication uses discovery at the configured authority to obtain signing keys. The API therefore checks the issuer, intended audience, signature and lifetime rather than accepting a payload because it contains a convincing role name.

The algorithm restriction is explicit: this implementation accepts RS256. The tests use that algorithm too; they do not independently exercise rejection of every other algorithm.

I also keep the middleware order visible: authentication runs before authorization. Each protected endpoint names its policy, while /health explicitly allows anonymous access.

Match a complete delegated scope

The read endpoint requires api.read. A scope claim can contain several space-separated permissions, so comparing the entire claim to one string would reject a legitimate combination. Searching for a substring would introduce the opposite problem: api.read.extra could accidentally satisfy api.read.

My ApiRead policy uses this assertion:

.RequireAssertion(context => context.User.FindAll("scp")
    .SelectMany(claim => claim.Value.Split(' ', StringSplitOptions.RemoveEmptyEntries))
    .Contains("api.read", StringComparer.Ordinal)));

It splits every scp claim into individual values and performs an exact, case-sensitive comparison. The policy also requires an authenticated user. A scope string alone cannot bypass token validation.

The tests include a successful token containing profile api.read and a rejected token containing api.read.extra. Those cases demonstrate the distinction between a complete permission and a similar-looking value. Case sensitivity is explicit in the implementation; the suite does not include a separate mixed-case input.

Give the write endpoint its own policy

The order endpoint requires the role Orders.Write. With RoleClaimType configured as roles, the policy is small:

options.AddPolicy("OrdersWrite", policy => policy
    .RequireAuthenticatedUser()
    .RequireRole("Orders.Write"));

I attach it to POST /orders, independently of the read policy. A valid caller missing the scope can still satisfy the order policy through its role. A valid caller missing the role can still satisfy the read policy through its scope. Both directions have test cases.

The README describes configuring the role for application access. The endpoint itself checks authentication and role membership; it does not additionally verify that the token came from a client-credentials flow. The test token builder normally includes both scope and role claims. These tests establish independent permission checks, not a complete distinction between delegated and application-only token types.

Make rejection behavior predictable

Missing or invalid credentials produce 401 responses on protected endpoints. The tests also check that these responses include a Bearer authentication challenge.

A token expired ten minutes earlier receives 401. The configured 30-second clock tolerance means I would not describe expiration as rejection at the exact instant of the timestamp. Boundary timing is not separately tested.

A different audience, an untrusted signing key and an incorrect issuer also receive 401. An authenticated token without the endpoint's permission receives 403. That distinction helps a caller separate authentication failure from insufficient authorization.

A token issued by another tenant would not match the single configured issuer. However, the negative test supplies https://untrusted.example/v2.0 as the issuer. It does not obtain a real token from another Entra tenant. The configured restriction is visible in code; cross-tenant integration remains unverified.

What the 14 cases prove

The suite uses xUnit and WebApplicationFactory to send HTTP requests through the application. Its factory creates temporary 2048-bit RSA keys, signs test JWTs, and supplies static discovery metadata containing the trusted public key. A separate key generates the untrusted-signature case.

The factory replaces discovery and signing-key material while preserving the production validation flags, issuer, audience, algorithm restriction and authorization policies. Identity-network requests are explicitly blocked. This avoids making local tests depend on tenant credentials or network availability.

One parameterized test has 14 inputs covering public health, anonymous requests, valid access, invalid credentials and independent permission failures. All 14 pass in CI at the revision cited below.

The GitHub Actions workflow runs the Release tests with .NET 8 on Ubuntu, and the run for that revision passed. Live discovery, key rotation, real consent flows and real tenant tokens still need integration validation.

Keep the sample's limits visible

The order endpoint returns an acknowledgement; it does not persist orders. These policies also do not implement ownership checks, per-customer data isolation or caller-application allowlists. Those decisions belong beside the relevant business operation.

All three excerpts come from Program.cs. The tests and README are pinned to the same revision, 5f05783815b8f7e727c3f0b7cde723f35788ee63.

If you need Microsoft Entra ID authentication in your ASP.NET Core API, write to me about your callers and the permissions you need to enforce.

How I Built a C# MCP Server with Single-Use Order Approvals

Martin Pisacreta — Wed, 28 Oct 2026 01:02:50 +0000

Giving an assistant a tool for reading orders is straightforward. Giving it a cancellation tool raises a different question: who authorizes the change? I wanted to explore that boundary without treating a model-generated confirmation as permission.

I built dotnet-mcp-orders-server, a small .NET 8 MCP server exposing fictional orders. It offers list, lookup and cancellation tools over stdio. Cancellation requires an independently recorded approval for one action and one exact order, with an expiration time.

The project has 12 tests, all passing in GitHub CI. Those tests exercise the tool methods and approval behavior; they do not establish an interactive connection with Claude or ChatGPT. Here is how I built the approval flow and where its guarantees end.

Keep the tool interface small

I expose three tools: list_orders, get_order and cancel_order. The first two read seeded, in-memory data. The third changes a pending order to cancelled. No external order system or payment provider is involved.

The cancellation tool accepts only an order ID. There is no approved boolean for the assistant to set, and no tool for creating approvals. This is the declaration from OrderTools.cs:

[McpServerTool(Name = "cancel_order")]
[Description("Cancel a pending fictional order only when an operator has independently recorded an unexpired, single-use approval. This tool cannot create approvals.")]
public Order CancelOrder([Description("Exact ID of the order approved for cancellation.")] string orderId)
    => Explain(() => orders.Cancel(orderId));

The description helps the assistant understand the contract. Enforcement lives in the service and approval store, so it still applies if a client ignores that description.

I use the MCP SDK's stdio transport and register the tool class with dependency injection. Application logs go to stderr because stdout is reserved for protocol messages. Mixing ordinary console output into that stream can break communication before business logic even runs.

Record permission outside the conversation

An operator runs the repository's separate Python approval command, supplying the approval directory and order ID. The command writes an approval containing cancel_order, the exact order ID and an expiration five minutes in the future.

It writes a temporary file in the destination directory, flushes it, and replaces the final JSON file. That avoids publishing partially written JSON during an ordinary update. I would not turn that helper into another model-accessible tool: doing so would let the caller manufacture the permission it needs.

The server reads its approval directory from ORDERS_APPROVAL_DIRECTORY, falling back to a directory beside the assembly. In a real setup, choosing that location and controlling who can write there are part of the authorization design. A path alone authenticates nobody.

Claim an approval before using it

Reading an approval and deleting it afterward would leave a race: two callers could both read the same permission before either removes it. My store first renames the file to a unique claimed name.

This excerpt from OrderService.cs shows the claim and validation:

File.Move(source, claimed);
moved = true;
var approval = JsonSerializer.Deserialize<CancellationApproval>(
    File.ReadAllText(claimed), JsonOptions);
return approval is not null &&
    approval.Action == "cancel_order" &&
    approval.OrderId == orderId &&
    approval.ExpiresAt > DateTimeOffset.UtcNow;

The rename is the point where competing consumers contend for the same source file. Validation then checks the action, order and expiration. A malformed document, inaccessible file or missing approval fails closed.

A finally block attempts to delete the claimed file after validation, including when validation rejects its contents. The store does not put an expired or malformed approval back into circulation. If cleanup fails, the claimed file may remain, but its name is no longer the approval filename consumed by later requests.

Before constructing paths, I restrict IDs to 1–64 ASCII letters, digits or hyphens. That prevents inputs such as ../outside from becoming paths under this naming scheme. It does not make an attacker-controlled directory safe.

Check business state as well as permission

Approval is only one condition. The order must exist and still be pending. I check those conditions under the service's lock before consuming permission.

The mutation path contains this excerpt:

if (order.Status != "pending")
    throw new InvalidOperationException("Only pending orders can be cancelled.");
if (!approvals.TryConsume(orderId))
    throw new InvalidOperationException("A valid external approval is required. No order was changed.");
var cancelled = order with { Status = "cancelled" };
orders[orderId] = cancelled;
return cancelled;

That lock coordinates calls within this service instance. It is not a distributed lock or a substitute for database concurrency control.

Expected failures become McpException messages at the tool boundary. A caller can distinguish missing approval from a missing order or an order that cannot be cancelled. I want the assistant to explain the rejection instead of repeatedly submitting the same forbidden operation.

What the 12 test cases cover

The suite calls OrderTools directly with a real file approval store in a temporary directory. It does not start a Claude session or exchange MCP messages over stdio.

Six individual cases cover listing seeded orders, reading an order, rejecting an unknown ID, rejecting cancellation without approval, consuming a valid approval and rejecting cancellation of a shipped order.

A parameterized test adds four invalid-approval cases: expired permission, a different order, a different action and malformed JSON. Another adds two unsafe-ID cases. That makes 12 executed cases, including the parameterized inputs.

The successful cancellation test checks the returned state, reads the changed order back and verifies that the approval directory is empty. It then creates a fresh service and confirms that the consumed approval cannot authorize another cancellation.

The GitHub Actions workflow restores the solution and runs Release tests with .NET 8 on Ubuntu. All 12 tests pass in CI.

Boundaries I would preserve in a production design

The approval directory must remain outside the model's writable filesystem and shell access. This sample does not establish an operating-system security boundary against an agent running as the same user with arbitrary shell access.

Orders reset on restart, while unused approval files can survive. I document removing outstanding approvals before restarting a session. Approval consumption and the in-memory state change are not a durable transaction: a crash between them can consume permission without completing cancellation.

For production, I would need durable order state, authenticated operator approval, audit records and explicit crash recovery. I would also add transport-level and client integration tests. The supplied Claude setup examples are configuration instructions, not evidence that an interactive connection succeeded.

All three C# excerpts are from OrderTools.cs and OrderService.cs at revision e21057a922624b1e7e1f2275b1cf47b2cc5d71b8.

If you need an MCP server with externally approved actions in your API, write to me about your workflow and the permissions you need to enforce.

How I Make Stripe Webhooks Idempotent in ASP.NET Core

Martin Pisacreta — Wed, 28 Oct 2026 00:57:02 +0000

A payment webhook can arrive twice even when nothing is wrong with my application. The uncomfortable case is when the second delivery arrives while the first one is still running. If both requests check whether an event exists before either inserts it, both can decide to apply the payment.

I built stripe-webhooks-dotnet to make those cases reproducible. The sample receives signed Stripe events, stores them in a durable inbox and processes local payment changes in a background worker. Its suite has 38 tests, passing in CI on .NET 8 and .NET 10. Here is the pattern, including the boundaries I would keep visible before adapting it to another API.

A retry is another delivery of the same work

An HTTP response can disappear after my server has committed a change. From the sender's perspective, that request failed. Retrying is reasonable, but running the business operation again may be expensive.

Returning a successful response quickly helps, but it does not make the operation idempotent. Neither does an in-memory collection of event IDs: it disappears on restart and cannot coordinate separate application instances.

I use the Stripe event ID as the inbox deduplication key. Two deliveries of that ID compete for one database row. This addresses repeated delivery of an event; business rules may also need protection against different events describing the same underlying operation.

Verify the original body first

Before trusting the event ID or storing the payload, I verify the signature. Stripe signs the original request body. Deserializing JSON and serializing it again can change whitespace or property ordering, so I keep the received body for verification.

This excerpt comes directly from WebhookReceiver.cs:

stripeEvent = EventUtility.ConstructEvent(
    json,
    signature,
    settings.WebhookSecret,
    tolerance: settings.SignatureToleranceSeconds,
    utcNow: clock.GetUtcNow().ToUnixTimeSeconds(),
    throwOnApiVersionMismatch: false);

The receiver limits the body before verification, with a default cap of 1 MB. Signature verification uses a configured tolerance, defaulting to 300 seconds, and an injected clock. Missing or invalid signatures receive a 400 response.

I check API-version compatibility separately after signature verification. A correctly signed event from an incompatible API release should produce a useful configuration error instead of being mislabeled as a bad signature. Disabling the SDK's combined version exception here does not mean accepting incompatible events.

Let the insert decide who wins

The next step is an insert, without a preliminary existence query. ProcessedEvents has a unique index on EventId. The receiver uses this statement:

var inserted = await db.Database.ExecuteSqlInterpolatedAsync(
    $"""
    INSERT INTO ProcessedEvents (EventId, Type, EventCreated, Payload, Status, Attempts, ReceivedAtUtc, NextAttemptAtUtc)
    VALUES ({stripeEvent.Id}, {stripeEvent.Type}, {created}, {json}, {nameof(EventStatus.Pending)}, 0, {receivedAt}, {receivedAt})
    ON CONFLICT (EventId) DO NOTHING
    """,
    cancellationToken);

The interpolation API supplies database parameters. The SQL conflict clause is SQLite-specific; I would adapt it deliberately when changing database providers.

One insert wins. A duplicate affects zero rows and receives a 200 response with a duplicate acknowledgement. The winner stores the verified payload as Pending before acknowledging acceptance.

That ordering is essential. If I acknowledge first and then crash before storage, Stripe has a successful response while my application has lost the work. Here, acceptance means durable receipt; it does not mean the payment handler has finished.

Make the queue disposable

After storage, the receiver attempts to enqueue the event ID into a bounded channel. The channel is a scheduling aid. The database remains the durable record.

If the channel is full, the receiver still acknowledges the stored event. A sweeper finds due Pending rows on startup and periodically afterward, then queues their IDs again. Losing the channel during a restart should delay processing rather than lose accepted events.

This also means the worker must tolerate receiving the same ID repeatedly. Deduplicating HTTP requests alone would leave a second duplication point inside the application.

Commit the claim and payment together

The processor opens a database transaction before claiming an event. Its conditional update is another excerpt from the repository:

var claimed = await db.ProcessedEvents
    .Where(e => e.EventId == eventId && e.Status == EventStatus.Pending)
    .ExecuteUpdateAsync(
        set => set
            .SetProperty(e => e.Status, EventStatus.Processed)
            .SetProperty(e => e.ProcessedAtUtc, clock.GetUtcNow().UtcDateTime),
        cancellationToken);

Zero affected rows means another execution has already moved the event out of Pending. Otherwise, the processor loads the stored payload, invokes the payment handler, saves the changes and commits.

Although the update sets Processed before the handler runs, that claim remains inside the transaction. If the handler throws, rollback undoes both the claim and the local payment change. A successful commit makes them durable together.

After failure, the processor records an attempt and schedules a retry with backoff. The defaults allow ten attempts. An exhausted event becomes Failed and needs operational attention: Stripe already received its acknowledgement, so recovery now belongs to my application.

What the tests actually exercise

The suite has 38 tests. The project targets .NET 10 and .NET 8, and CI runs the suite on both runtimes.

The tests host the application through WebApplicationFactory with SQLite files and generated webhook secrets. An independent signing helper constructs headers, while a handler wrapper counts calls and injects failures. That gives stronger evidence than checking only the final payment row.

Coverage includes invalid signatures, duplicate delivery, competing worker claims, rollback, retry exhaustion, recovery of stored Pending events, queue backpressure and stale payment snapshots. The concurrent-delivery case performs ten rounds of 25 parallel requests: 250 requests within that test, rather than 250 separate tests.

Where I draw the boundary

The once-only guarantee concerns local database effects committed with the inbox claim. Sending email, shipping an order or calling another API introduces another failure boundary. I would add an outbox and downstream idempotency before extending that guarantee to external actions.

SQLite serializes writers. These concurrency tests do not establish SQL Server or PostgreSQL locking behavior, distributed throughput or production capacity. I would validate the chosen provider under representative contention.

Deduplication also does not solve event ordering. The sample compares event timestamps and includes refund-specific tie handling; those rules need review when adding event types. Failed-event monitoring, replay procedures and payload retention remain operational responsibilities.

The three excerpts above are from WebhookReceiver.cs and EventProcessor.cs at revision 53545ae. I keep that revision explicit so readers can compare the explanation with the implementation.

If you need idempotent Stripe webhooks in your ASP.NET Core API, write to me about your payment flow and the failure cases you need to handle.