What this source supports: The phrase was observed in the live flow; the reset-message screenshot should accompany the request.
The simple layer stands alone; open the technical layer for limits and objections.
1
The big idea
By the end, you can
Calculate the purchase-to-reset window
State both possible interpretations
Request preservation before the deadline
The purchase occurred on July 4. On July 23, the current flow stated that extra credits remain valid for 90 days. The account-holder's capture showed a July 28 reset—only 24 days after purchase—without saying whether it reached the top-up. The coexistence of those messages creates ambiguity; it does not prove a breach.
Think of it as… a ticket whose current screen advertises three months while another message shows a date in 24 days without identifying the ticket. You therefore request the rule applied to the purchase instead of guessing.
Under the hood
The conflict is conditional but strong: if reset reaches the purchased lot, validity is inconsistent; if it reaches monthly credits only, the interface is ambiguous. Either way, support should preserve the lot and explain the rule.
2
Visual map
Read left to right: each stage limits what the next may claim.The case becomes stronger when the evidence boundary stays visible.
Day 0
Day 24
Day 90
Promise
Reset
No rollover
Monthly
Purchased
Preserve
Capture
Explain
Resolve
Scenario A
Monthly only
Scenario B
Top-up included
3
In practice
This record turns the reasoning into verifiable fields without personal identifiers.
Use what you learned to review the request and seek professional guidance if legal or banking consequences matter. Now read what Sections 9.3 and 9.4 help establish—and what they do not.