Understand saved card states
At the source version reviewed for this guide, Customer App can show a saved- cards area only when the current project exposes an enabled Braintree saved-card capability. The profile entry, card list, Add card action, and Delete card action are therefore conditional. This source boundary is not a deployed-availability guarantee.
The current source does not establish saved-card support for Stripe. It also does not provide a current default-card choice or edit-card action.
Recognize the visible state
| State | Safe interpretation |
|---|---|
| Profile entry absent | The saved-card capability was not resolved as available in the current context; no reason or account conclusion follows |
| Loading | Customer App is resolving capability or requesting the current list |
| Unavailable | The current project did not return the supported saved-card capability |
| Empty | The authorized response contains no card rows for the current view |
| Masked list | Customer App presents a card brand and last four digits for each returned reference |
| Load error | Current list state is unknown; an earlier display may be stale |
An empty or unavailable state does not prove that the customer has never saved a card with a provider, that another project has no card, or that a card can be added. A masked row is not proof that the reference is still usable.
Masked presentation and ownership
The list should expose only the minimum display fields needed to distinguish a saved reference, such as brand and last four digits. It must not expose a full card number, security code, provider token, session credential, internal identifier, or provider response.
Every list, add, refresh, and delete operation must be authorized for the exact current account, project, configured payment capability, and saved-card target. A row returned to the interface is not, by itself, proof of ownership. Changing account, project, or session must invalidate earlier rows, cached capability, pending provider work, and late callbacks.
Adding a card is an external handoff
When Add card is available, the current Braintree path opens an embedded external provider surface. That surface can collect sensitive payment details outside the ordinary Customer App form state. Opening it is a provider handoff, not proof that a card was created.
Closing the surface, receiving a provider message, or refreshing the list does not by itself establish that Ordering saved the reference for the current account. Only a fresh, authorized Ordering result can establish the resulting masked list state. If the handoff closes, fails, or returns an unrecognized result, treat the outcome as unknown and do not repeat the action automatically.
This guide does not provide card-entry steps or provider setup instructions.
Deleting a saved reference
Delete is a distinct financial-account action and should require an explicit confirmation for one masked target. A local row disappearing does not prove that provider and Ordering state have converged.
If the response is lost, the app closes, or the account/project changes, keep the outcome unknown until a fresh authorized list is available. Do not submit a second deletion solely because the old row is still visible, and do not infer that deleting a saved reference cancels a charge, order, subscription, wallet event, or provider account.
Troubleshoot without card data
| Symptom | Safe response |
|---|---|
| Saved cards entry is missing | Confirm the active account and project; do not change payment-provider configuration |
| List is empty or unavailable | Treat availability and ownership as unknown outside the current authorized view |
| List fails to load | Retry one ordinary authorized refresh; never enter card data as a test |
| Add-card surface does not open or closes | Leave the outcome unknown; do not paste a provider address or credential into another surface |
| Added card does not appear | Reconcile with one fresh authorized list before another add attempt |
| Delete returns an error or no result | Reconcile the list before repeating; do not test with another saved card |
| Card appears after account/project change | Stop, avoid selecting or deleting it, sign out if safe, and use an approved support channel |
Never share a full card number, security code, token, provider reference, session value, screenshot of payment details, or copied WebView content for documentation or troubleshooting.
Accessibility expectations
Availability, loading, empty, error, masked card, Add card, Delete card, confirmation, busy, success, unknown outcome, and external-provider transition need distinct semantic names, roles, states, and predictable focus. A card row must be distinguishable without relying only on its icon or brand styling.
The masked label should be announced as a card brand plus last four digits, without reading decorative mask characters as a full number. Delete must name the masked target and remain separate from the row. Opening and closing the external surface must move focus deliberately, and errors must be announced without exposing payment data. These are verification requirements, not a claim of current accessibility certification.
Recertification triggers
Revalidate this reference after changes to capability discovery, supported gateway families, list fields, account/project/session binding, cached provider state, external-surface origin or message handling, add/delete settlement, default/edit behavior, masking, navigation, or accessibility. Source inspection alone does not certify deployed API or provider behavior.
Related guides: Profile and account overview · Understand payment-method availability · Understand checkout failures and retries · Understand privacy and consent · Understand platform and accessibility behavior