Saved Payment Methods Panel
Saved cards as token rows with the processor architecture explained and the no silent save footer.
Saved cards as token rows with the processor architecture explained and the no silent save footer.
The Ecommerce Collection unlocks the source for every Ecommerce block. All Access unlocks every Collection.
Already purchased? Log in
Saved Payment Methods Panel lists three cards as ruled rows: brand, last four digits, expiry, a default tag, and a delete link. The lede states the architecture plainly: “Every row here is a token at the payment processor. We never saw the full number, so there is no full number here to steal.” The delete footer adds: the processor token dies with the row, no archive, no undo, the next checkout simply asks for the card again. The bottom note closes the consent loop: cards land here only when the save box is ticked at checkout, never saved silently.
Cards are one array of three rows. The token explanation and the no silent save footer are the two trust mechanisms; the panel without them is a plain card list.
Reach for this block on the account payment tab inside the account section. The delete action must wire to the processor token removal endpoint in production, the text makes a promise the backend must keep or the copy misleads.
A natural flow around it on an Ecommerce Pro page:
Before
After
One strong use is the three card wallet with the token explanation. Other saved methods panels:
Tip: the no silent save footer is the consent signal buyers increasingly expect; it belongs on every store running saved cards.