Warn customers before their saved card expires and billing fails

On the first of each month at 8am, check my Authorize.Net stored payment profiles for cards that expire within the next 60 days, so I can get ahead of the failures before they happen. This is a preventive workflow. These cards have not failed yet, and the entire point is to fix them before they do, so do not turn this into a post failure dunning flow that reacts to declined charges.

Start with Get Customer Payment Profile List (CIM) to pull the stored payment profiles and identify the cards expiring in the next 60 days. Card expiration is formatted YYYY-MM, so compare on year and month rather than an exact day. Page through the results with the paging object, using a limit of up to 1000 and a 1-based offset, incrementing the offset until fewer than limit rows come back.

Then call Get Subscription List (ARB) filtered to active subscriptions, and match those subscriptions back to the customers whose cards are expiring. Skip any stored profile that has no active recurring subscription so we are not emailing dormant customers. For each customer who survives that filter, call Get Customer Profile (CIM) to pull their name and email address.

For every customer whose expiring card is attached to active recurring billing, send a personalized Gmail message with Send a Message, asking them to update their card on file before their next billing date. Reference only the card brand, the last four digits, and the expiry month. Never ask the customer to reply with card details and never put a full card number in the email. Write each message individually so it reads like a note from us rather than a bulk blast.

Finally, post a summary to my billing Slack channel using the Slack Bot Send a Message operation, ranked by monthly revenue at risk. List each customer, their subscription amount, and the month their card expires, and lead with the total monthly revenue at risk across the whole list.

Two Authorize.Net API details to handle carefully. Every response carries a top-level messages.resultCode of either Ok or Error, which must be checked before reading the payload. JSON responses also begin with a UTF-8 byte order mark that needs stripping before parsing, or the parse will fail.

Because the window is 60 days and this runs monthly, a customer can surface on two consecutive runs. That is intended and acts as a natural second reminder. When someone is being contacted a second time, word the email as a friendly follow up rather than repeating the first message verbatim.