Overview
Understand the Card Program Connect model, responsibilities, and payment prerequisites.
Card Program Connect associates cards from an existing card program with a Facto user. The cardholder signs in, selects cards, and approves the change on a page provided by the Card Program or its authorized platform. The backend then submits the final card list to the Engine. Facto stores an independent binding for each card and checks the binding, consent, PaymentRoute, and limits before payment authorization.
Integration model
Card Program Connect has three parts:
- Connect intent. Facto creates a 15-minute connect intent and sends
connect_hintandconnect_intent_idto the registeredconnect_page_url. - Card list. The backend reads the current bindings and submits the complete
desired_cardsset approved by the cardholder. The update is transactional, andIdempotency-Keymakes retries safe. - Per-card payment configuration. Each active binding has its own consent and may reference zero or one PaymentRoute. The cardholder manages that route in Facto.
Facto enables this capability per environment and Card Program. Development and Production are configured separately; access in one environment does not grant access in another.
Responsibilities
| Owner | Responsibilities |
|---|---|
| Card Program or authorized platform | Cardholder sign-in, card display, consent text, and approval page; connect-hint verification, current-list reads, final-list submission, idempotency keys, and audit references on the backend. |
| Cardholder | Select cards, approve the disclosed data, and attach or remove a PaymentRoute for each card in Facto. |
| Facto | Create and track connect intents; store per-card bindings and consent; provide card-portfolio and PaymentRoute management; run payment-authorization checks. |
The Card Program cannot read the cardholder's PaymentRoute or
payment_readiness. The cardholder manages both through their Facto session.
Prerequisites
Complete the following configuration before integration:
- The Card Program is
activein the target environment, with the required connection capability enabled. - An active Program Connection grants the operation being called.
- Facto has issued Provider Connection server credentials for the same environment.
- The
connect_page_urlis registered and reachable by Facto.
Security requirements
Keep server credentials on the backend. After reading connect_hint and
connect_intent_id from the URL fragment, remove the fragment immediately.
Submit only an opaque card_ref and display metadata in the card list. Never
submit a PAN, CVV, or another payment credential.
Connection and payment states
| Layer | State or object | Meaning |
|---|---|---|
| Access | Active Program Connection | The backend may call approved operations for the Card Program; this state alone does not indicate whether a user card binding exists. |
| Connect intent | applied or no_change | The Engine processed the final card list; no PaymentRoute is implied. |
| Card binding | binding_status: active | The card is associated with the Facto user; payment still depends on route, limit, and authorization checks. |
| Route association | status: associated | The card has a PaymentRoute; every payment still rechecks the route and runtime conditions. |
| Payment authorization | status: processing | The request passed authorization checks and entered asynchronous processing; settlement and reconciliation are separate. |
Related guides
- Permission model: Card Programs, Provider Connections, and Program Connections.
- Connection flow: connect intents, the card-selection page, and final-list submission.
- Card bindings and consent: per-card bindings, consent scopes, and revocation.
- PaymentRoute and authorization: PaymentRoute association and pre-authorization checks.
- API and SDK: endpoints, authentication, idempotency, and SDK coverage.