Group
  • Payments

    Implement refunds that stay in sync

    Handles full and partial refunds with access revocation, idempotency, and records that reconcile.

    • Improve quality
    • Automate workflows
    • Intermediate
    • General

Free Prompt

Audit and fix how refunds work in my app: issuing them, recording them, and what happens to the customer's access afterward. Implement: refunds issued through the provider's API (never by editing local records to look refunded), full and partial refund support with amounts validated against the original charge (can't refund more than was charged), idempotency on the refund call so a retried request doesn't refund twice, and every refund recorded locally with the provider's refund ID for reconciliation. Decide and implement the access policy: for one-time purchases, does access revoke on refund (usual) or persist; for subscriptions, refunding a payment is separate from canceling, and both need handling. Process the provider's refund webhook too, since refunds issued from the provider's dashboard must sync back to my records, and log who issued each refund if admins can trigger them. Don't auto-refund on cancellation unless that's the stated policy. Don't expose refund endpoints without admin authorization. Deliver: the refund flow with the access policy documented, webhook sync, and verification: issue a full refund and a partial refund in test mode, confirm the provider record, the local record, and the access change all agree, then retry the same refund request and confirm no double refund.

What This Does / How This Helps

Makes refunds a first-class flow: issued through the provider, recorded locally, synced from webhooks, with a deliberate answer for what happens to access. Half-built refund handling produces the worst support situations: the customer was refunded but still has access (or the reverse), a retried admin click refunded twice, or a refund issued in the Stripe dashboard never made it back to your records, so your books and the provider's disagree. The verification pass proves the three systems agree (provider, local records, access state) and that the double-refund path is closed.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts