Customer Profiles
Customer Profiles API for Payments
A customer profiles API for payments that gives teams repeat-billing identity, default payment methods, merchant customer IDs, and billing context on one public customer record.
Why teams choose this primitive
Flint customers already hold merchant customer IDs, notes, tax flags, addresses, and a default payment method reference on the public API.
The customer model sits directly beside payment methods, orders, subscriptions, invoices, and checkout sessions, which makes repeat billing flows easier to keep coherent.
That is stronger than rebuilding customer identity and saved billing context in a parallel app table that drifts away from the payment surface.
Repeat purchases, subscriptions, invoices, and saved cards all need to point back to one durable customer record.
Your system needs merchant customer IDs and internal notes without rebuilding a second customer store beside the payment stack.
Default payment methods, tax flags, and billing or shipping context should live on the payment platform's customer object.
Why Developers Reach for This
Teams searching customer profile APIs for payments usually need more than a loose email field. They need a durable customer record that can hold saved payment methods, internal cross-reference IDs, default billing behavior, and repeat purchase context over time.
Repeat billing identity
Create one customer record that can own saved payment methods, default billing behavior, and later recurring activity.
Cross-reference internal systems
Store your internal account identifier on the Flint customer instead of maintaining a fragile mapping table with no payment context.
Support-visible billing context
Keep notes, addresses, and tax treatment attached to the same customer object support teams see during payment investigations.
Customer-linked checkout and invoices
Reuse the same customer across orders, checkout sessions, invoices, and subscriptions instead of passing partial identity through each flow independently.
Choose Something Else When
Implementation References
Implementation References
Customers API
Create, update, list, and cross-reference customer records with billing and shipping context.
Payment Methods API
Save payment methods against a Flint customer and set the customer's default billing method.
Quickstart
See the standard create-customer first flow that Flint's payment model builds on.
Related Pages
Explore saved billing methods, off-session charging, and recurring customer flows
These pages cover the next architectural steps once a durable Flint customer record becomes part of the billing model.
Saved Payment Methods API for Platforms
Use this when the direct evaluation is billing credential setup and reuse rather than the broader customer record model.
Off-Session Payments API
Useful when customer profiles need to support later billing without the buyer present.
Subscriptions API with Trials and Setup Fees
Go here when the customer record is mainly a foundation for recurring billing and hosted subscription signup.