Visa Click to Pay

Issuers

Use Cases

      

Activating Click to Pay

A new consumer applies for their first card

  • Alex decides to open an account with Digital Bank which includes a Visa Debit card.
  • After completing the application form, Alex accepts Digital Bank Terms and Conditions, which includes Click to Pay provisions, and submits the application.
  • Alex is informed that the application was successful.
  • Alex receives the Click to Pay pre-activated card by post.

Fig.1. Illustrative UX for a new consumer opening an account with a Digital Bank.

The issuer activates Click to Pay on the cards of an existing customer

  • Digital Bank informs Alex that Click to Pay will become a standard feature of their Visa cards, explain the features and benefits of Click to Pay and provide the option for Alex to opt out.
  • Alex is excited to use Click to Pay and waits for the activation date advised by Digital Bank. On the activation date, Digital Bank informs Alex that Click to Pay is now active on the card.
  • Alex opens the Digital Bank app.
  • Alex lands on a Click to Pay intro screen.
  • Alex opens the Click to Pay section for a Visa card.

Fig.2. Illustrative UX for an existing consumer opening another account with a Digital Bank.

The Click to Pay activation use cases in Fig. 1&2 are achieved by using Visa ID & Credential’s Enroll Data API.

Note: only selected parameters are called out here for brevity
  • Issuer invokes POST /v1/enrollData with
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • consumerInformation – email, phone, name fields, etc… 
    • paymentInstruments – accounNumber, expirationDate, billingAddress, etc…
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the enrollment
    • If the operation is completed and successful, the response will have
      • status = COMPLETED 
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS

An existing consumer, who already has cards with Click to Pay, applies for a new card

  • Alex decides to apply for a credit card.
  • On the Digital Bank app, after completing all the required steps, Alex submits the request for a credit card.
  • Alex receives a new Digital Bank credit card that comes with a pre-activated Click to Pay feature.  

Fig.3. Illustrative UX for a consumer, who already has card/s in Click to Pay with the same Digital Bank, applying for a new card.

The Click to Pay activation use case in Fig.3 is achieved by using Visa ID & Credential’s Enroll Payment Instruments API.

Note: only selected parameters are called out here for brevity
  • Issuer invokes POST /v1/enrollPaymentInstruments with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • paymentInstruments – accounNumber, expirationDate, billingAddress, etc…
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the enrollment
    • If the operation is completed and successful, the response will have
      • status = COMPLETED
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS

Viewing Click to Pay Details

A consumer reviews the Click to Pay details of one of their cards

  • Alex opens the Digital Bank app.
  • Alex navigates to the Card Settings screen of a Visa card.
  • Alex opens the Click to Pay section and sees all related details.

Fig.4. Illustrative UX for a consumer, who has card/s in Click to Pay, reviewing the details of their cards in Click to Pay. 

The Click to Pay information access use case in Fig.4 is achieved by using Visa ID & Credential’s Get Data API.

Note: only selected parameters are called out here for brevity

  • Issuer invokes POST /v1/getData with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID
  • If the operation is successful, the Issuer will receive a 200 response with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • consumerInformation data 
    • paymentInstruments data

Editing Click to Pay Details

A consumer updates the email and/or mobile number associated with Click to Pay

  • Alex has a new email and/or mobile number and wants to replace the current Click to Pay email and mobile number with the new ones to keep shopping quick, safe and easy.
  • On the Digital Bank app, Alex goes to the card settings screen. 
  • Alex opens the Click to Pay section and locates the FAQs.
  • Alex learns that to update the Click to Pay email and mobile number they also need to update the ones on the Digital Bank app as the two are the same. 
  • Alex contacts Digital Bank and asks to update email and mobile number.
  • If the email and mobile number are new: Digital Bank asks Alex to validate the new details before replacing the old details.
  • Digital Bank updates email and mobile number for Alex in all their systems and sends the update to Click to Pay.

Fig.5. Illustrative UX on how a consumer would find instructions on changing personal information in Click to Pay.

The Click to Pay email and/or mobile update use case in Fig.5 is achieved by using Visa ID & Credential’s Manage Consumer Information API.

Note: only selected parameters are called out here for brevity

  • Issuer invokes POST /v1/manageConsumerInformation  with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • consumerInformation data
      • a different email and /or mobile will be provided
      • data fields that are not changing must be populated with existing values.
    • Note: It is recommended for Issuers to invoke Get Data API prior to the Manage Consumer Data API to know the latest state of the consumer record in Click to Pay and populate all data fields correctly.
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the update.
    • If the operation is completed and successful, the response will have
      • status = COMPLETED 
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS

Note: only selected parameters are called out here for brevity

  • Issuer invokes POST /v1/managePaymentInstruments with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • paymentIntruments data
      • type must be CARD 
      • accounNumber must exist in the consumer record in Click to Pay 
      • new billing address is provided 
      • data fields that are not changing must be populated with existing values.
    • Note: It is recommended for Issuers to invoke Get Data API prior to the Manage Payment Instruments API to know the latest state of the payment instrument data in Click to Pay and populate all data fields correctly.
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the update.
    • If the operation is completed and successful, the response will have
      • status = COMPLETED
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS

Opting Out from Click to Pay

A consumer opts out one card from Click to Pay

  • Alex wants to opt out of Click to Pay.
  • Within the Digital Bank app, Alex navigates to the Card Settings screen.
  • Alex opens the Click to Pay section and locates the FAQs.
  • Alex learns that to remove CTP they need to contact Digital Bank.
  • Alex contacts Digital Bank asking to opt out the card from Click to Pay.
  • Alex can now see that Click to Pay has been deactivated.

Fig.6. Illustrative UX on how a consumer would find instructions on opting out from Click to Pay for one of his cards.

The Click to Pay opt out use case for a single card in Fig.6 is achieved by using Visa ID & Credential’s Delete Payment Instruments API.

Note: only selected parameters are called out here for brevity

  • Issuer invokes POST /v1/deletePaymentInstruments with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID 
    • paymentIntruments to be deleted
      • type must be CARD 
      • accounNumber must exist in the consumer record in Click to Pay
    • Note: It is recommended for Issuers to invoke Get Data API before Delete Payment Instruments API to know the latest state of the consumer record in Click to Pay and ensure the card to be deleted exist in Click to Pay for that consumer record.
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the update.
    • If the operation is completed and successful, the response will have
      • status = COMPLETED 
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS

Note: only selected parameters are called out here for brevity

  • Issuer invokes POST /v1/deleteConsumerInformation with 
    • intent = CLICK_TO_PAY 
    • consumerInformation.externalConsumerID
  • Issuer will receive a 202 response with a
    • requestTraceId – to be used when retrieving the outcome of the operation
  • Issuer invokes GET /v1/requestStatus/{requestTraceId} to know the outcome of the update.
    • If the operation is completed and successful, the response will have
      • status = COMPLETED 
      • consumerInformation.externalConsumerID 
      • details
        • intent =CLICK_TO_PAY 
        • status = SUCCESS
    • Note: All paymentInstruments in the consumer record will be deleted as well from Click to Pay.

 

Disclaimer: This page is provided on an “as is, where is” basis, “with all faults” known and unknown. This page could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein: these changes will be incorporated in new editions of the document. VISA may make improvements and/or changes in the product(s) and/or the program(s) described in this document at any time. Where potential future functionality is highlighted, visa does not provide any warranty on whether such functionality will be available or if it will be delivered in any particular time. To the maximum extent permitted by applicable law, visa explicitly disclaims all warranties, express or implied, regarding the information contained herein, including any implied warranty of merchantability, fitness for a particular purpose, and non-infringement.

If you have technical questions or questions regarding a Visa service or questions about this document, please contact your Visa representative.