Cómo contamos el ahorro
El bloque Ahorro del informe (/app/informe) y la tarjeta del panel muestran lo que Burnbound ha evitado que pague tu organización en un mes natural (UTC). Esta página explica qué se cuenta, qué no y por qué. Versión de la metodología: 2.
Dos cifras que nunca se suman
- Evitado con certeza. Dinero que habría salido y se habría perdido seguro: un cobro doble o un pago a una dirección que no es la del vendedor.
- Gasto contenido (estimado). Pagos que pararon tus topes y tus reglas, y que el agente no hizo después por otro camino. Es gasto que no ha ocurrido, no necesariamente dinero tirado.
Los importes van en USD (USDC 1:1). Tu plan se cobra en euros: el panel pone las dos cosas una al lado de la otra y nunca las convierte con un tipo de cambio.
Evitado con certeza
| Categoría | Qué cuenta |
|---|---|
| Cobro doble evitado | El agente repitió un pago con la misma clave de idempotencia y recibió la misma autorización, sin pagar dos veces. Cuenta una vez por pago, y solo si el pago original se cobró. Una nueva firma de un pago MPP cuya firma anterior caducó no cuenta. |
| Pago a una dirección falsa | Un pago denegado por la protección frente a inyección: resource_host_mismatch, pay_to_denied, pay_to_not_verified, challenge_host_not_allowed, challenge_path_not_allowed o challenge_amount_exceeded. |
| Retención rechazada por una señal de seguridad | Una persona rechazó un pago retenido porque su 402 parecía dar instrucciones al agente o porque iba a una dirección de cobro nueva. |
Gasto contenido (estimado)
| Categoría | Qué cuenta |
|---|---|
| Topes y ritmo | amount_exceeds_per_transaction, daily_cap_exceeded, velocity_tx_exceeded, velocity_usd_exceeded y member_cap_exceeded. |
| Reglas propias | rule_denied, rule_limit_exceeded y decision_webhook_denied. Solo reglas y webhooks en enforce: lo que una regla o un webhook en observe habría hecho no cuenta nunca. |
| Hosts y vendedores sin verificar | host_not_allowed y seller_not_verified. |
| Retención rechazada por una persona | Una persona rechazó un pago retenido por el umbral de aprobación, por ser el primer pago a un host del catálogo, por una regla propia o por tu webhook de decisión. |
Para no inflar la cifra:
- Reintento por otro camino. Si el mismo agente paga con éxito al mismo host en las 24 horas siguientes, ese bloqueo no cuenta: fue un retraso, no un ahorro.
- Bucles. El mismo bloqueo repetido (mismo agente, mismo recurso, mismo importe, misma red y mismos códigos) cuenta una sola vez mientras no pase una hora entre un intento y el siguiente. Un intento de inyección, un bloqueo por encima de tu máximo por pago y un bloqueo por host o vendedor sin verificar se agrupan por host: cuentan una vez aunque el vendedor cambie el recurso o el importe, porque los pone él. Un bloqueo que no contó porque el agente lo esquivó no hace callar al siguiente.
- Solo lo que de verdad podía salir. El importe de un pago denegado lo pone el vendedor, y un 402 hostil puede pedir lo que quiera.
- Si en el momento de decidir Burnbound ya sabía que el saldo de la cartera no cubría el pago (con la comisión máxima en Tempo), ese bloqueo no cuenta: el pago habría fallado igualmente, porque un pago x402 o Tempo es todo o nada. Burnbound nunca espera a leer el saldo para decidir.
- Si no lo sabía, un bloqueo que pide más que tu máximo por pago, o un recurso de otro host, no suma importe en ninguna cifra: el informe dice cuántos hay. Cualquier otro bloqueo pasó tu máximo por pago.
- Los importes de tarjeta y de reembolso vienen de Stripe, no de un vendedor, y cuentan tal cual.
- Un bloqueo con varios códigos va a la primera categoría, en el orden de la tabla, de la primera tabla que case. Si no casa ninguna de esa tabla, va a la primera de la segunda, también en su orden. El orden en que vengan los códigos no cambia nada.
Lo que nunca cuenta
- Un bloqueo cuyo saldo no cubría el pago, que se cuenta como
insufficient_funds. - Un bloqueo con un código que dice que el pago habría fallado o no era posible, aunque traiga otros códigos:
insufficient_funds,invalid_amount,network_not_allowed,asset_not_allowed,method_not_allowed,currency_not_supported,no_payable_offer,offer_not_chosen,plan_limit_reached,card_not_linked,decision_timeoutydecision_webhook_unavailable. - Una aprobación que caducó sin que nadie decidiera: el agente puede volver a pedirla.
- Los pagos que fallaron, caducaron o no se pudieron firmar (
payment.failed,payment.expiredypayment.sign_failed). - Los vendedores que cobran y no entregan. Todavía no hay una señal de eso en el momento del pago.
- El dinero de prueba: redes de prueba y el modo de prueba de Stripe. Se muestra aparte.
- Los bloqueos guardados antes de que la auditoría anotara la red del pago. Se cuentan aparte, como «sin red».
Lo que se escapó
Los pagos que el vigilante de la cadena vio fuera de la política (payment.out_of_policy, firma en el cliente) se muestran junto al ahorro. No se restan, pero se enseñan.
Planes
Team, Business y la prueba de 30 días ven las dos cifras con su desglose, lo que se escapó, los mayores ahorros del mes y el mes anterior. Free ve las dos cifras del mes actual. Ningún plan ve nada anterior a lo que muestra su auditoría: lo anterior se deja fuera, nunca se estima, y el bloque dice desde qué fecha cuenta.
La tarjeta del panel muestra las dos cifras del mes actual de toda la organización, con cualquier plan.