Summary

  • Twilio's Fraud Guard Promise can credit Verify and SMS fees for SMS pumping messages that its guard should have stopped. The customer must have kept Fraud Guard in Max Protection Mode, filed a support ticket within 30 days after the sending month ended, and won Twilio's review.
  • The terms exclude credits when Verify Geo Permissions, Safe List or the RiskCheck parameter was enabled on the affected numbers. These are also tools operators may use to manage blocking and false positives. Eligibility turns on the actual configuration, not the reassuring name of the product.

The refund counter has switches

An authentication service can spend real money on messages that nobody wanted. SMS pumping drives verification traffic toward numbers that produce charges. Twilio's Fraud Guard is built to detect and block that pattern. Its legal Promise offers a credit for Verify and SMS fees if fraudulent messages get through when Fraud Guard should have caught them. The word credit matters: Twilio reviews the claim and decides which messages qualify. A dashboard estimate of costs avoided is a different number.

The first switch is protection level. Twilio's documentation calls Standard the default; the Promise requires Fraud Guard to be enabled and maintained in Max Protection Mode. Max blocks more aggressively, and Twilio itself says false positives may occasionally occur at that setting. A business choosing between conversion and blocking therefore confronts the trade before any refund request. The Promise attaches to one side of it.

The next switch looks like a customer-service fix. Twilio tells operators they can put known phone numbers on a Safe List so Fraud Guard and Geo permissions never block them. The Promise's eligibility terms then say that affected numbers must not have Safe List, Verify Geo Permissions or the RiskCheck parameter enabled. Those terms group the three as False Positive Prevention Features. It is an unusually sharp piece of product design: a setting that helps a legitimate user get a code can also change the customer's position if a pumping claim later concerns that number.

The condition is tied to affected numbers; it is not a claim that one Safe List entry voids every possible credit on an account.

The clock is just as narrow. The customer must submit a support ticket within 30 days after the end of the calendar month in which the fraudulent messages were sent, supply the required details and any additional information Twilio requests. Twilio must confirm the messages were pumping traffic that Max mode should have blocked. The terms add conditions for accounts sending on behalf of other entities and for custom verification codes. They make the credit the sole remedy under this Promise.

The published terms give no claim approval rate or example customer loss. The missing fact for a real dispute is the configuration on the affected numbers and Twilio's decision on the messages. For an operator, the immediate lesson is mechanical: keep a dated record of Max mode, per-number exceptions, attempt-level overrides, sending month and support ticket. A safety setting remembered after the bill arrives is an expensive kind of memory.

Sources