A price rise, a free trial becoming paid, and a yearly renewal all break the expectation someone had when they set up AutoPay. Those moments earn a card in the chat. A monthly payment at the same price does not. It becomes a short receipt, and several routine renewals fold into one digest instead of stacking up.

The message policy is based on what changed, not on whether a payment exists. An unanswered change can receive up to two reminders, each pointing back to the original card rather than restating everything. An expiring mandate also earns a message, because payments will stop after its end date. The result is a chat that stays quiet by default but becomes specific when attention can still change the outcome.

An early direction put Approve and Decline in front of every renewal. It did not survive the product logic. A UPI AutoPay debit goes through unless something stops it, so Approve does nothing and two equal buttons can make people tap the wrong one out of habit.

The change card has one action that changes the outcome: Don't pay this one. Doing nothing keeps the payment on track. Choosing the action explains that the merchant decides what happens to the plan, then offers Undo for the immediate mistake. The warning and the control live together in the chat, at the moment the decision matters.

A skipped debit should not disappear after the tap. The chat keeps a plain status line with Undo. Once the planned date passes, a follow-up says that it was not paid and offers a way to turn AutoPay back on for future dates. That makes the consequence clear without pretending that one skipped payment is the same as ending a subscription.

On the other path, a routine renewal receives a receipt and nothing to act on. A payment flow should describe what happened next, not leave a decision looking active after it has been made. The same pattern applies after a payment succeeds: a receipt closes the loop in the same place the warning appeared.

AutoPay should not imply that every payment can be invisible. In the concept, a debit above ₹15,000 cannot be taken automatically. The bank needs the person's UPI PIN every time, so the message names the amount, explains why it is waiting, and offers the specific action to pay with that PIN.

The difference is important: this is not a reminder to cancel, it is a payment that cannot proceed without approval. Making that boundary explicit avoids a dangerous ambiguity between a payment someone may want to stop and a payment that is waiting for the security step required to complete it.

A changed price is worth reviewing, but it is not an error. A failed debit is different. The payment has not moved and the person needs to know why, such as insufficient balance, a daily UPI limit, or a bank that could not process the debit. The message also makes the possible consequence clear: the plan may pause if it remains unpaid.

Amber is for a change. Red is reserved for money that did not move. The prototype shows a Retry payment action to demonstrate the recovery state and its receipt. In a real product, the more honest version may be Pay now or a notice when the merchant retries, because the merchant initiates the AutoPay debit.

Each card links to Manage, where the next amount, date, notification preference, and current status sit together. The same information also lives in Payments → Manage autopay, so the chat is an effective entry point without becoming the only place to understand a recurring payment.

“Not mine” is deliberately separate from skipping one date. It stops future payments from that merchant and reports the mandate, so it asks once for confirmation and remains undoable from that payment's detail view. A single skipped debit, a cancelled mandate, and a suspected payment are different problems and need different controls.

The concept does not try to make every AutoPay payment feel urgent. It sets a notification policy that matches the payment's state: changes get a choice, normal renewals get a receipt, failed debits get an explanation, and high-value payments get an approval step.

The underlying product question is feasibility: WhatsApp can only show mandates it can access, and a one-payment pause would need to work with UPI and merchant rules. Those constraints shape the concept, but the design principle remains simple: put notice, context, and control together before the payment is taken.