Visa Subscription Manager (VSM) allows issuers to provide cardholders the self-serve capability to monitor and manage their subscription payments through the issuer's mobile application.

Cardholders can:

•   Review all card-not-present transactions with merchants that have stored credentials.

•   Get a comprehensive view of participating merchants storing their card information. These are merchants where the cardholders transacted in the last 13 months.

•   View their recurring and installment payments, including subscriptions, such as streaming services, food delivery, magazines, gym memberships, club memberships, and utility.

•   Pause or stop recurring and installment payments from being authorized, cleared, and settled through VisaNet.

•   Restart payments while subscribing to a subscription merchant.

1. The cardholder requests to view their subscriptions. The issuer calls the Card-on-File (COF) Data Service endpoint, retrieves a list of COF transactions and related attributes, and displays the transactions on the issuer mobile or web application.
2. The cardholder selects the transaction they want to manage. The issuer calls the "Raw Merchant Card-on-File Data Service" endpoint to retrieve the raw merchant name and display more details of the card, if the cardholder has multiple subscriptions with the merchant.
3. If the cardholder decides to pause a payment till the end of the following month or to stop a payment for up to 60 months, the issuer calls the "Add Merchant Stop Instruction" endpoint to establish these stop instructions.
   • The instruction is allocated a unique ID and, at a minimum, contains the Visa card number, the stop payment type, the active date range, and a merchant identifier, such as Card Acceptor ID, Merchant Name, or Payment Facilitator ID / Sub-Merchant ID. It may optionally include additional transaction identifiers, such as minimum and maximum transaction amounts or MCC, to ensure that the intended payments get stopped.
4. At the designated time, a merchant submits an authorization request for a subscription payment that the cardholder had previously canceled.
5. VisaNet matches authorization and clearing messages, based on:
   • Transactions that qualify for stopping.
   • The criteria defined in the stop payment instruction.
6. If an authorization message matches a clearing message, VisaNet:
   • Declines the authorization request with a specific response code, either R0 or R1, and sends an advice to the issuer.
   • Returns a clearing message to the acquirer with a specific return/reclassification reason code, either C0 or C1.
   • *Acquirers are expected to pass this decline response code to the merchant. The merchant is not expected to resubmit the authorization request. If the transaction is submitted without authorization for clearing and settlement, VisaNet will re-attempt to match and return the transaction to the acquirer with the corresponding return response code.
7. If the cardholder decides to resume a payment that was previously stopped, the issuer calls the "Search for Stop Instruction by PAN" endpoint to find the ID of the stop instruction. Once the ID is retrieved, the issuer calls the "Cancel Stop Instruction" endpoint to deactivate the stop instruction. An authorization request placed by the merchant will no longer be declined, provided all other criteria are met.

1. Clients can consume Visa Subscription Manager (VSM) APIs on VDP to avail this service. The API uses Message Level Encryption (MLE), which encrypts the whole payload.
2. Visa retains the right to review the implementation of the API by issuers before onboarding to ensure that they are being used appropriately.
3. While VSM empowers cardholders to manage their payment subscription, it does not release them from the legal responsibility of paying the merchant for goods or services as per their agreement with the merchant. This must be communicated to cardholders. Participating issuers are responsible for any necessary cardholder notifications related hereto.
4. Client signs the contract for Visa Subscription Manager, and for the solution to be delivered through VSM APIs via VDP.
5. Client completes the VSM enrollment form and provides Visa with client information, a list of BIDs and BINs to get access to VSM. This is important to ensure the BID and BINs are configured for VSM.
6. Client works with their Visa implementation specialist to get access to the Visa Developer Center to open a project and obtain the correct API credentials using the two-way secure Socket Layer (SSL)/mutual authentication method.
7. The app requesting the API is registered in VDP:
8. VDP assigns a unique App ID (VDP ID) and username/password along with the certificate key. 
9. The app logs in to the VDP portal using the assigned username/password to request API access.
10. VDP client registration is stored on Visa side along with the client BID.
11. Once a project is on-boarded onto VDP Sandbox and given access to a certain API service, the client will receive a sandbox clientId.
12. Client can start integrating their mobile application with the VSM APIs and start testing.
13. Once the app is ready to go live, the client works with their Visa implementation specialist to receive a Production clientId and submits a 'Go Live' request to the VDP Production team.