Vaulting and Customers
The card reader can collect a physically presented payment method and store it for future transactions.
Last updated
Was this helpful?
The card reader can collect a physically presented payment method and store it for future transactions.
Last updated
Was this helpful?
If you're building a checkout experience that might require additional charges in the future when the customer is no longer present, you may choose to create a flow that vaults the payment method presented to the card reader.
These use cases might include keeping a card on file for members, signing a customer up for a subscription, or performing a checkout in which some items are shipped or fulfilled today and others, later.
These vaulted payment methods can be linked to a customer profile (customer ID) in Braintree which can include additional customer data such as name, email, phone #, etc... or they can be used as standalone payment method tokens (payment method ID) for future payments against a customer profile stored in your own CRM or POS application.
The customer object is an important optional component of the Braintree gateway. Use customer ID's to store and organize . A single customer ID can have multiple payment methods.
This process can be used to request the vaulting of a PaymentMethod without a related transaction.
This will initialize the card reader for vaulting flow. You will receive a inStoreContextPayload.id
in the response to poll and check the status of the customer's interaction with the reader.
When the context comes back with a status of COMPLETE, you will receive a paymentMethod.id
in the response to use in future requests to make charges.
This process can be used when you wish to place an immediate charge on a card for a known amount, but also save the card for future usage. This might be common where a customer leaves with 3 items today, but 1 item will ship in the future from a warehouse.
Simply include the vaultPaymentMethodAfterTransacting
attribute in the requestChargeFromInStoreReader
mutation. This will initialize the card reader for the normal charge flow. You will receive a inStoreContextPayload.id
in the response to poll and check the status of the customer's interaction with the reader.
When the context comes back with a status of COMPLETE, you will receive a RequestChargeInStoreContext.transaction.customer
object in the response to use in future requests to make charges.
Use the standard Braintree eCommerce GraphQL mutations to make future charges on the paymentMethod.id generated using the above vaulting flows.
When digital wallets (such as Apple Pay, Google Pay, and Samsung Pay) are used on the card reader, and a vaulted payment method is requested, that vaulted payment method is stored in the Braintree vault. When that paymentMethod.id token is then used for a subsequent transaction, an MIT (merchant-initiated transaction) flag will be automatically applied to the transaction. This will result in these transactions having an auth expiry window of 24 hours. This means that you should factor in this auth expiry window into your capture flow and re-auth logic.
To query more data about the payment method verification check our GraphQL API documentation on the object.
(Sale)
(Auth)
(Capture)
The token is great for performing future charges but is unique per vaulting request, so it is not recommended to be used for customer data analytics.
The is a unique token per card number that can be used for customer analytics; however, it cannot be used for performing future charges.
The uniqueNumberIdentifer
is only available for cards and not available for payment methods (PayPal and Venmo).
There are a when it comes to requesting to vault a payment method. You may request a paymentMethodId
token upon a successful auth attempt or "ALWAYS" for every auth attempt, even if unsuccessful.