Chrome/Payments client-side flows

Last updated (including links) January 2018

Chrome Downstream (card unmasking)

  1. A credit card is selected in the Autofill suggestions dropdown, which triggers AutofillManager::FillOrPreviewForm, which triggers AutofillManager::FillOrPreviewCreditCardForm
  2. If the form is being filled with a MASKED_SERVER_CARD, a new payments::FullCardRequest is created, and FullCardRequest::GetFullCard is called
  3. Some checks occur, and then the card unmask dialog is shown while Risk data is loaded in parallel
  4. AutofillManager::ShowUnmaskPrompt calls ChromeAutofillClient::ShowUnmaskPrompt, which creates a CardUnmaskPromptView and calls CardUnmaskPromptControllerImpl::ShowPrompt with it
  5. On Desktop, a CardUnmaskPromptViews is shown -- [ Card unmask dialog appears ] --
  6. On Desktop, if the dialog is accepted, CardUnmaskPromptViews::Accept calls CardUnmaskPromptControllerImpl::OnUnmaskResponse with the values entered on the dialog
  7. The CardUnmaskDelegate::UnmaskResponse is populated with these values, then the delegate’s OnUnmaskResponse is called
  8. FullCardRequest::OnUnmaskResponse uses these values to set up the PaymentsClient::UnmaskRequestDetails
  9. Once the user has accepted the dialog and Risk data is loaded, FullCardRequest::SendUnmaskCardRequest calls PaymentsClient::UnmaskCard
  10. PaymentsClient::IssueRequest calls PaymentsClient::InitializeUrlFetcher to set the Payments URL to be called (specified by UnmaskCardRequest), then fires off an HTTP request to it -- [ GetRealPanAction called ] --
  11. Google Payments receives the request and returns a response
  12. PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
  13. UnmaskCardRequest::RespondToDelegate calls AutofillManager::OnDidGetRealPan, which calls FullCardRequest::OnDidGetRealPan
  14. OnUnmaskVerificationResult is called on the |ui_delegate_|, which updates the UI based on the RPC’s result through a long chain of calls that ultimately end at CardUnmaskPromptControllerImpl::OnVerificationResult and CardUnmaskPromptViews::GotVerificationResult
  15. Back in FullCardRequest::OnDidGetRealPan, the RPC’s result determines how to update the web page's form

Chrome Upstream (upload credit card save)

  1. The user submits a form, triggering AutofillManager::OnFormSubmitted. If the form was autofillable, FormDataImporter::ImportFormData is called
  2. An inner FormDataImporter::ImportFormData helper is called, which begins the process of importing both credit card and address profile information
  3. FormDataImporter::ImportCreditCard is called which tries to detect if a new credit card was entered on the form, storing it in |imported_credit_card| if so
  4. FormDataImporter::ImportAddressProfiles is called, which tries to import one address profile per form section (maximum of 2)
  5. If the submitted form included a credit card and meets Chrome Upstream requirements, prepare to attempt to offer credit card upload by calling CreditCardSaveManager::AttemptToOfferCardUploadSave
  6. The payments::PaymentsClient::UploadRequestDetails is initialized, which sets the card in the request -- [ Client-side credit card validation ] --
  7. The form is searched for a valid CVC value, setting it in the request if found, or taking note of the problem if not (no CVC field, empty CVC field, or invalid CVC value) -- [ Client-side address validation ] --
  8. CreditCardSaveManager::SetProfilesForCreditCardUpload is called, which performs Chrome-side Upstream profile verifications, logging any problems found in |upload_decision_metrics_| (no address, conflicting names, no name, conflicting postal codes, no postal code)
  9. If CVC is missing, the CVC fix flow is enabled, and no other problems were found, |should_cvc_be_requested_| is set to true in order to display the client-side CVC fix flow when upload is offered. Otherwise, if CVC is missing, |upload_decision_metrics_| records that it was not found
  10. If any problems were found and the Send Detected Values experiment is disabled, offering upload save is aborted
  11. AttemptToOfferCardUploadSave calls PaymentsClient::GetUploadDetails with the set of seen addresses, detected values bitmask, and active Chrome experiments
  12. PaymentsClient::GetUploadDetails prepares to issue a GetUploadDetailsRequest (a call to Google Payments’ GetDetailsForSaveCard)
  13. PaymentsClient::IssueRequest calls PaymentsClient::InitializeUrlFetcher to set the Payments URL to be called (specified by GetUploadDetailsRequest), then fires off an HTTP request to it -- [ GetDetailsForSaveCardAction called ] --
  14. Google Payments receives the request and returns a response
  15. PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
  16. GetUploadDetailsRequest::RespondToDelegate calls CreditCardSaveManager::OnDidGetUploadDetails, which decides how to proceed based on the GetUploadDetailsRequest’s response:
    • On a success, the user is prompted to save the card to Google Payments, Risk data is loaded in parallel, and metrics note that upload was offered
    • On a failure, if name+address+CVC were found, the user is prompted to save locally, and metrics note that upload was not offered
  17. The final UMA and UKM metric decisions are finally logged
  18. ChromeAutofillClient::ConfirmSaveCreditCardToCloud offers to save the card to Google by surfacing an infobar on Android or a bubble on web
  19. Upon accepting save, the infobar/bubble fires a callback for CreditCardSaveManager::OnUserDidAcceptUpload
  20. Once both the user accepts save and Risk data is loaded, CreditCardSaveManager::SendUploadCardRequest is called, which sets CVC in the request if the CVC fix flow was activated
  21. PaymentsClient::UploadCard prepares to issue an UploadCardRequest (a call to Google Payments’ SaveCard)
  22. PaymentsClient::IssueRequest calls PaymentsClient::InitializeUrlFetcher to set the Payments URL to be called (specified by UploadCardRequest), then fires off an HTTP request to it -- [ SaveCardAction called ] --
  23. Google Payments receives the request and returns a response
  24. PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
  25. UploadCardRequest::RespondToDelegate calls CreditCardSaveManager::OnDidUploadCard, which, on a success, saves the credit card as a FULL_SERVER_CARD (so it doesn’t need to be unmasked on next use on the same device)