Enabling Credit Card
Payments at Delivery
- Identified a high-friction payment problem blocking deliveries at Lucid Motors
- Designed and shipped a credit card payment method end-to-end as the sole payments PM
- Migrated ACH data and unified all payment types into one ledger across Salesforce and SAP
- Unlocked same-day delivery for the first time in company history
Three payment methods.
All of them painful.
When a customer finalized their Lucid purchase, a remaining balance was due at delivery. Every available payment method introduced delay, manual work, or confusion: for customers and for the internal team.
Settlement & Visibility Gap
- Many customers struggled with the ACH 2FA process and setup
- 2–3 day settlement window with no real-time visibility
- Advisors had to check Salesforce daily to see if payment showed as Paid
- ACH data lived in a legacy system, not yet on the unified payment ledger
Manual Wire
- Customer copies routing numbers from portal
- Initiates wire from their own bank
- Must tell us they sent it
- Finance manually logs receipt in Salesforce
Physical Check
- Customer trips to the bank
- Mail or hand-deliver the check
- Delivery cannot be scheduled until funds clear
- 3 to 5 business days minimum
The original goals were operational: automate payment logging and give the sales team full visibility and refund capability without Stripe access. The bigger unlock only became clear post-launch.
- Same-day payment settlement and auto-logging across Salesforce, MongoDB, Kafka, and SAP
- Migrate ACH payment data from legacy system into the unified ledger, visible in Salesforce and SAP
- Refund functionality inside Salesforce, no Stripe dashboard access needed
- Chargebacks and refunds visible in Salesforce payment history
- Every prior method had a 24+ hour settlement lag, the invisible ceiling on how fast we could hand a car over
- Card authorization is instant. A customer could reserve online, finalize payment, and drive home the same day: for the first time in company history
How we confirmed the problem.
Seven requirements.
One coherent system.
I was the sole PM for the payments team, no PM above me on this feature. I owned the problem, the spec, the architecture decisions, and QA sign-off.
Credit Card as New Method
Enabled in the delivery portal via Stripe. Market code (USA, CA, DE…) routes each charge to the correct merchant account automatically.
Overpayment Prevention
Input validated against remaining balance in real time. If the amount entered exceeds what's owed or the $8k cap, the UI tells you exactly which limit was hit.
Multi-Payment Support
Customers can split the balance across multiple card transactions. Each payment is logged immediately and the remaining balance updates live.
$8,000 Credit Card Cap
Hard limit agreed with Finance and Risk. Enforced client-side and server-side. Balances above $8k require ACH or wire for the remainder.
3% Convenience Fee
Applied only to the payment amount, not the vehicle total. Disclosed transparently before confirmation. Base amount reduces balance; fee is a separate line in Salesforce.
Salesforce Payment Ledger + Refunds
Every payment logged with Order ID, VIN, Market, Stripe PI, base amount, and fee separately. Refunds issuable by the sales team directly from Salesforce, no Stripe dashboard access required.
Legacy ACH Data Migration
ACH payment history migrated from the legacy system into the unified Lucid payment ledger. Both CC and ACH payments now visible together in Salesforce and consumable by SAP CPI for full reconciliation.
After kickoff, we uncovered that the Salesforce API returning the account balance was not reliable: it was surfacing incorrect amounts, which meant customers could have seen the wrong balance due in the portal. I immediately brought in cross-functional leads across Sales, Finance, and Delivery Ops and reframed the conversation: not as a delay, but as a data integrity fix we were making in parallel before launch.
I brought in cross-functional leads across Sales, Finance, and Delivery Ops and reframed the conversation immediately. The message was not "we are delayed." It was: "We found a data integrity issue and we are fixing it in parallel before launch." That framing held the timeline narrative and got us alignment to fix it correctly rather than pressure to ship around it. I then coordinated directly with the enterprise systems team to resolve the calculation logic alongside our own build.
The feature was only as trustworthy as the balance data behind it. Shipping incorrect balances in a payments product is not a "fix it in v2" situation: a customer could have been overcharged or undercharged at the most important financial moment of their car purchase. This reinforced a principle I now apply to every payments project: validate the system of record before designing the experience on top of it.
2026 · Air Grand Touring · Stellar White Metallic
Lucid Air
| Record ID | Date | Method | Market | Base Amount | Conv. Fee | Card Total | Stripe PI | Status | Action |
|---|
base_amount and convenience_fee as separate fields so downstream systems can reconcile against Stripe's total charge.
details & issue refunds
| PI ID | Date | Customer | Amount Charged | Base Amt | Fee | Status | Metadata |
|---|
metadata with order_id, vin, market, and base_amount. This lets finance match every Stripe charge back to a Salesforce order — and confirms that the total charge = base_amount + convenience_fee, not a reduction of the order balance.
full Stripe record & metadata
| Transfer ID | Date | Customer | Amount | Bank | Status | Metadata |
|---|
metadata fields apply — order_id, vin, market. No convenience fee applies to ACH. Finance can filter by order_id to pull all ACH and card charges for a single order in one query.
to view full record & metadata
Specifically, what I owned.
How we defined
done, and done well.
I defined success criteria before we wrote code, across customer experience, operational efficiency, and financial integrity. Here's how to read the cards below:
Within the first weeks of launch, same-day delivery conversions appeared for the first time in company history. End-of-month and end-of-quarter spikes were especially visible: advisors could now close deals and hand over cars the same day, something the settlement lag of every prior payment method had made impossible. I escalated this immediately to my VP for C-Level recognition.
What I'd do
differently, and where I'd
take it next.
Shipping v1 gave me three clear misses I'd correct, two durable lessons, and a roadmap I was actively building when I left.
Write a calculation spec before engineering touches code
The tax bug, applying 8% to Adjusted Cap Cost ÷ 36 instead of the base monthly payment, inflated the customer balance by ~$87. A simple worked-example test matrix in the PRD would have caught it in sprint one, not late QA.
Bring advisors into the design phase, not just discovery
I gathered advisor feedback at the problem stage but didn't loop them back in during UI design. They interact with customers at the exact moment of payment: one working session mid-design would have shaped the ledger layout and fee disclosure language much earlier.
Soft launch in one market before full rollout
We launched across all markets at once. A 2-week USA-only pilot would have let us validate the $8k cap against real payment patterns, confirm Salesforce logging at scale, and create a clear go/no-go gate before broader exposure.
The $8k cap needed data, not intuition
Finance and Risk set $8k based on chargeback intuition, which was reasonable, but I later found median delivery balances were $1,500 to $2,500. That data should have anchored the cap from day one. It might have landed lower with the same coverage, or higher with more confidence.
Ask: what else becomes possible once the friction is gone?
Same-day delivery wasn't in the brief. I discovered it during a post-launch review when I saw numerous reservations convert into same-day deliveries. I quickly raised this to my VP so they could celebrate the win with C-Level leadership. The lesson: when solving friction, always ask what unlocks upstream: the strategic story is usually bigger than the feature request.
Where I would have taken it next.
The infrastructure, Stripe, Salesforce, and Kafka, was intentionally built to power more than a web form. The roadmap below was what I was actively scoping before I left.
Canada & EU Market Rollout
The payment container was built to route by market code from day one. Expanding CC to CA and EU was a configuration change plus legal review, not a re-architecture. Next step was a market-by-market enablement plan with regional ops teams.
Data-Driven Cap + Sales Manager Overrides
Post-launch data showing median balances of $1,500 to $2,500 would drive a cap revisit. Beyond that: let sales managers approve per-customer exceptions via a Salesforce-native override. The payment container would read the cap value directly from the Salesforce API, so a manager could adjust the limit for a specific customer without any engineering involvement.
Dynamic Risk Scoring via Stripe Radar
The $8k cap is a blunt instrument. Stripe Radar enables transaction-level risk scoring: a higher-trust customer shouldn't have the same ceiling as a first-time buyer. Replace the flat cap with a dynamic limit tied to card and customer history.
Tap or Swipe at the Studio: No Portal Required
The biggest item on my roadmap. Today, customers enter card details through the web portal. The next step was bringing this into our retail point-of-sale: a tap or swipe at the Lucid studio, facilitated by the sales advisor. The POS would look up the account by Order ID, VIN, email, phone, or customer name, pull the open balance, and process payment in one motion. No portal, no form-filling. The customer experience becomes identical to any premium retail purchase, backed by the exact same Stripe infrastructure, Salesforce logging, and Kafka events we already built and owned.