Last updated (including links) January 2018
- A credit card is selected in the Autofill suggestions dropdown, which triggers AutofillManager::FillOrPreviewForm, which triggers AutofillManager::FillOrPreviewCreditCardForm
- If the form is being filled with a MASKED_SERVER_CARD, a new payments::FullCardRequest is created, and FullCardRequest::GetFullCard is called
- Some checks occur, and then the card unmask dialog is shown while Risk data is loaded in parallel
- AutofillManager::ShowUnmaskPrompt calls ChromeAutofillClient::ShowUnmaskPrompt, which creates a CardUnmaskPromptView and calls CardUnmaskPromptControllerImpl::ShowPrompt with it
- On Desktop, a CardUnmaskPromptViews is shown -- [ Card unmask dialog appears ] --
- On Desktop, if the dialog is accepted, CardUnmaskPromptViews::Accept calls CardUnmaskPromptControllerImpl::OnUnmaskResponse with the values entered on the dialog
- The CardUnmaskDelegate::UnmaskResponse is populated with these values, then the delegate’s OnUnmaskResponse is called
- FullCardRequest::OnUnmaskResponse uses these values to set up the PaymentsClient::UnmaskRequestDetails
- Once the user has accepted the dialog and Risk data is loaded, FullCardRequest::SendUnmaskCardRequest calls PaymentsClient::UnmaskCard
- 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 ] --
- Google Payments receives the request and returns a response
- PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
- UnmaskCardRequest::RespondToDelegate calls AutofillManager::OnDidGetRealPan, which calls FullCardRequest::OnDidGetRealPan
- 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 - Back in FullCardRequest::OnDidGetRealPan, the RPC’s result determines how
to update the web page's
form
- On a failure, AutofillManager::OnFullCardRequestFailed clears the form
- On a success, AutofillManager::OnFullCardRequestSucceeded logs the event and fills the form
- The user submits a form, triggering AutofillManager::OnFormSubmitted. If the form was autofillable, FormDataImporter::ImportFormData is called
- An inner FormDataImporter::ImportFormData helper is called, which begins the process of importing both credit card and address profile information
- 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 - FormDataImporter::ImportAddressProfiles is called, which tries to import one address profile per form section (maximum of 2)
- 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
- The payments::PaymentsClient::UploadRequestDetails is initialized, which sets the card in the request -- [ Client-side credit card validation ] --
- 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 ] --
- 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) - 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 - If any problems were found and the Send Detected Values experiment is disabled, offering upload save is aborted
- AttemptToOfferCardUploadSave calls PaymentsClient::GetUploadDetails with the set of seen addresses, detected values bitmask, and active Chrome experiments
- PaymentsClient::GetUploadDetails prepares to issue a GetUploadDetailsRequest (a call to Google Payments’ GetDetailsForSaveCard)
- 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 ] --
- Google Payments receives the request and returns a response
- PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
- 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
- The final UMA and UKM metric decisions are finally logged
- ChromeAutofillClient::ConfirmSaveCreditCardToCloud offers to save the card to Google by surfacing an infobar on Android or a bubble on web **-- [ Offer to save UI is shown ] --**
- Upon accepting save, the infobar/bubble fires a callback for CreditCardSaveManager::OnUserDidAcceptUpload **-- [ User clicked save ] --**
- 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
- PaymentsClient::UploadCard prepares to issue an UploadCardRequest (a call to Google Payments’ SaveCard)
- 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 ] --
- Google Payments receives the request and returns a response
- PaymentsClient::OnURLFetchComplete is called upon receiving a response, checks for errors, and calls the request-specific RespondToDelegate function
- 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)