We define each product based on two factors:

1. Payment experience that the product enables and;
2. The relationship between the Cardholder and the Merchant. With Stored Payment Tokens the Cardholder has a direct relationship with the Merchant. The Cardholder intentionally stores their payment credentials with that Merchant for the purpose of recurring and stored payments. With Cloud Wallets the Cardholder has a direct relationship with a wallet for the purpose of paying at multiple Merchants, such as guest checkout.

Yes. Discover Stored Payment Tokens are automatically updated through an API connection, eliminating the need for a manual request from the Merchant. Discover Stored Payment Tokens also offer the additional benefit of storing a Payment Token instead of the Cardholder’s PAN. Once available, Merchants will be able to route Debit tokens to Discover Global Network (DGN) or PULSE the same way they do today with PAN.

A Merchant, Acquirer, Payment Gateway, wallet or other digital enabler that supports Merchants can potentially become token requestors. Please reach out to your relationship manager for additional details about becoming a token requestor.

At this time, there is not a difference, at the network level, between tokenized vs. non-tokenized transactions. However, there could be slight process nuances with some products. For example, Secure Remote Commerce (SRC) token transactions have a richer authentication process, but the Network is not making decisions or declining transactions for fraud/risk scoring.

A Merchant, an Acquirer, or other entity that supports Merchants can work with us directly to implement the product.

1. Legal Agreement Framework.

• Acquirer – subject to Stored Payment Tokens language in Acquirer Operating Regulations.
• Direct Merchant - subject to Stored Payment Tokens language in Merchant Operating Regulations.
• Payment Gateway or other entity that works with Merchants – will need to execute Payment Enabler Product Agreement (PEPA)

2. Connection and Certification.

• Client provides URL endpoints to connect to our API and certifies their code to test cases.

3. Testing and Launch.

• Once certification is complete and launch plan is in place, client is boarded in production and launch begins.
  
  

NOTE: For all environments, Third-Party Gateway certificates must be certificate authority (CA) signed as this is a standard production gateway requirement. JSON Web Encryption (JWE) certificates can be self-signed.