M
Market Suite.io
### The Problem
Currently, when a client pays an invoice and their card is saved to their contact profile under
Payments → Cards on File
, the card's expiration date is visible in the UI — but it is completely inaccessible to the platform's automation engine, workflow triggers, smart list filters, and contact reporting.
This means there is no native way to:
  • Query contacts whose cards expire within a given timeframe
  • Build a smart list of "cards expiring this month"
  • Trigger a proactive workflow to notify clients before their card expires
  • Generate a report of at-risk auto-pay accounts
The only available workaround is to
manually duplicate
the expiry date into a separate custom contact field — an inelegant, error-prone bridge that shouldn't be necessary when the data already exists within the platform.
---
### Why This Is NOT a Security or PCI Concern
This is an important distinction that we'd like the product team to consider carefully.
PCI-DSS compliance rightly governs the protection of
sensitive cardholder data
— specifically:
  • Primary Account Numbers (PANs / full card numbers)
  • CVV/CVC codes
  • Cardholder names combined with card numbers
Card
expiration dates
, however, are explicitly
not classified as sensitive data
under PCI-DSS when stored or used in isolation. They carry zero fraud risk on their own — an expiry month and year, without a card number, CVV, and billing address, is completely useless to a bad actor.
Furthermore, the expiry date is
already displayed in the platform's own UI
on the contact's payment profile. If it were a legitimate security risk to surface this field, it would not be shown in the interface at all.
This is therefore
not a security architecture issue
— it is a
product integration gap
between the Payments subsystem and the Contact/Automation engine. The two subsystems simply don't share this non-sensitive metadata field, and there is no compliance reason preventing them from doing so.
---
### The Ask
We are requesting that the card-on-file
expiration date
be promoted to a
native, queryable contact-level property
, enabling:
  1. Smart List Filtering
    — e.g., "Card Expiry Month = [current month]" or "Card Expiry Date is within the next [15/30/45/60 days]"
  2. Workflow Trigger Support
    — via the existing
    Custom Date Reminder
    trigger, so a workflow can fire X days before the expiry date and send the client a proactive email to update their payment method
  3. Contact Reporting
    — surface expiring cards in dashboard views or exportable reports
---
### Real-World Impact
For any business running
recurring MRR billing or subscription auto-pay
, this gap has direct revenue consequences:
  • A declined charge due to an expired card disrupts cash flow
  • Reactive "payment failed" notifications damage client relationships
  • The manual workaround (custom field entry) introduces human error and requires ongoing maintenance
A proactive "your card is expiring soon — please update" email, sent automatically 2–4 weeks before the charge date, eliminates all of these problems. The data to power it already exists in the platform. It simply needs to be surfaced where automation can reach it, and takes a potentially client-friction reactive encounter (some clients find an email notice of "Your payment was DECLINED." as a stress-inducing, embarrasing situation, whereas this simple proactive fix would promote cashflow continuity + avoid the awkward "DECLINED" email.
---
### Proposed Implementation (Suggested)
  • Add
    "Card Expiry Date"
    as a read-only, system-managed contact field, auto-populated from the payment subsystem when a card is saved
  • Make it available as a filter in
    Smart Lists
    and
    Contact Search
  • Make it compatible with the
    Custom Date Reminder
    workflow trigger
  • No UI masking changes required — the field would behave identically to how it already appears in the payment profile
---
### Precedent Within the Platform
This request follows the same pattern as the existing feature request to make
Opportunity custom date fields
available in workflow triggers — where users are similarly forced to copy date data from the Opportunity object into a contact field just to enable automation. The community has clearly identified cross-subsystem data accessibility as a systemic need, and this request is another instance of the same underlying gap.
---
Thank you for considering this. This is a high-value, low-disruption enhancement that would meaningfully improve billing reliability and client experience for agencies and businesses managing recurring revenue.
-JT
MarketSuite.io