One Card Per Case: Building Stripe Virtual Cards Into Litify

Case expenses at a plaintiff firm come from everywhere: filing fees, medical records requests, expert retainers, court reporters. When those charges run through shared company cards, reconciliation becomes a monthly exercise in detective work. Someone has to look at a statement line and figure out which of a thousand open cases it belongs to.

‍

A high-volume personal injury firm on the East Coast wanted to solve this at the source: a unique credit card number for every matter, issued and controlled from inside Litify.

‍

The first platform evaluated had no point-and-click Salesforce integration, but it did have an open API, so building on it looked viable. The evaluation stopped at a hard limit: it would not pass card details over the integration. Without the card number reaching the user inside Litify, the whole premise fails.

‍

Stripe's API does support it. That single constraint decided the platform.

Issue and manage a virtual card per matter, without users ever leaving Litify.

‍

Key goals:

‍

• Provision a virtual card for every qualifying matter

• Deactivate the card automatically when the case reaches an end state

• Write every Stripe transaction back to the matter as a classified expense

• Give finance visibility when a charge fails or a limit is hit

We built the integration on Stripe's Issuing API, with Apex handling the callouts and a Lightning Web Component surfacing each card inside Litify.

‍

Card Lifecycle

‍

Cards are issued through a batch utility that finds qualifying matters without an active card and provisions them in controlled batches, each one carrying the matter's display name and record ID as Stripe metadata so the card is identifiable on both sides. Qualifying matters are open or stayed personal injury and civil rights cases where the client record has an email address on file.

‍

Stripe rate-limits card issuing, so the callouts run asynchronously with the batch size and the delay between calls held in configuration rather than hardcoded. Each cardholder is created before its card, in a separate queued step, which keeps a large provisioning run inside Salesforce governor limits.

‍

When the matter status moves to Dropped, Referred Out, Subbed, Settlement or Closed, a record-triggered flow calls Stripe and deactivates the card automatically. Cards can also be deactivated manually from the card record, and reassigned to a different matter when needed.

‍

Expense Writeback

‍

A Stripe webhook, exposed through a dedicated REST endpoint, listens for issuing authorizations and creates an expense record on the matter. Each expense carries the charge amount, the transaction date, a paid status, the merchant name, and the Stripe transaction ID for traceability. Records are created under a credit card charge record type and default to an unclassified expense type, so accounting starts from a categorized record on the right case rather than a raw statement line.

‍

Controls and Alerts

‍

Cards carry an all-time spending limit rather than being prefunded, set centrally so the firm can adjust it without touching code. Failed charges trigger a webhook-driven email notification to a finance distribution group and the matter team, so a declined card surfaces immediately instead of at month-end.

‍

Access is scoped by role through permission sets: finance, intake managers, medical managers, ownership, and the personal injury and workers' compensation teams. A formula field checks whether the current user sits on the matter team, which supports the firm's need to spot a card being used outside its intended case. Each card is scoped to a single matter, so exposure stays limited to one case rather than a shared firm account.

‍

Rollout

‍

We deployed the integration through UAT into production and released it in phases: a small group of finance and operations users first, then the wider team. It went live across the firm's active personal injury and civil rights caseload.

Reconciliation happens at the record level rather than the statement level. Each charge arrives on the matter it belongs to, already carrying an expense type and a merchant name, so there is no manual step of tracing spend back to a case. The integration covers roughly a thousand active matters.

‍

The lifecycle automation addresses a second gap. Cards deactivate when a matter reaches a closing status, so they do not stay open by default on cases the firm has already resolved. Combined with the failed-charge alerts, finance gets a signal on the day a charge is declined rather than at the end of the month.

‍

Managing case expenses across a large caseload? We'd be happy to talk through your options. Reach out to us at https://www.echots.com/schedule-a-call.