The authentication can occur in three different environments:
- Payment integrator's Android app
- Payment integrator's mobile website
- Payment integrator's desktop website
Regardless of the flow, Google hands off the user interaction to the Payment integrator's software. The payment integrator can choose to show the user an interface or simply return immediately if it already has the appropriate data. All flows result in the integrator producing an AuthenticationResponse. This response is signed and sent back to Google.
The mobile and desktop websites must follow the WebRedirect Authentication API Specification, while the Android App flow must follow the Android Authentication API Specification.
Integrators should implement an Android APK solution to authenticate the users. This authentication is a different modality, but the same purpose as the authentication provided by the Web authentication.
A user authenticates with the payment integrator via an Android Activity. The authentication intent is invoked during account association and for user-challenges. To prevent Android from terminating Play in the background during authentication, the integrator needs to include the following in the activity theme.
<item name="android:windowIsTranslucent">true</item>
Method definition
The intent needs to have these properties:
Method properties | |
---|---|
Action |
com.google.android.payments.standard.AUTHENTICATE_V1 |
Category | android.intent.category.DEFAULT |
Request
Fields | |
---|---|
gspAuthenticationRequest
|
AuthenticationRequest
Authentication request. |
gspAssociationId
|
string
If present, this contains an identifier that the integrator uses to look up credentials for the user that is challenged. If this is not present, the user has the option to change the account identification. |
Response
After the user completes authentication, your application needs to send a result intent back to Google. If authentication is successful, create an intent and add the encrypted encoded gspAuthenticationResponse as an extra. Next, set the activity result to the appropriate result code.
...
result.setExtra("gspAuthenticationResponse", gspAuthenticationResponse);
setResult(Activity.RESULT_OK, result);
...
finish();
Result
Fields | |||||||
---|---|---|---|---|---|---|---|
result |
int
|
Extras
Fields | |
---|---|
gspAuthenticationResponse |
AuthenticationResponse
Authentication response. This encoded value must not exceed 1KB. |
Other activity requirements
The activity that supports the above mentioned AUTHENTICATE_V1
action must
also check that callers of the API only come from Google-signed applications.
This will help prevent other apps from trying to invoke your activity and
retrieve identity tokens. This can be done by using the supplied
StandardPaymentUtils.verifyCallingActivityIsGoogleSigned
right after super.onCreate
within your
Activity
implementation.
Here's a sample:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
StandardPaymentsUtils.verifyCallingActivityIsGoogleSigned(this);
....
}
All activities invoked within the authenticate
flow must supply an activity
theme that has windowIsTranslucent=true
. This must be done with the
AndroidManifest android:theme attribute and not using Context.setTheme()
.
Programmatically, setting the theme doesn’t work correctly for window
translucency. Google will enforce that the first activity launched follows this
pattern but any sub activities that are also launched must also follow this
pattern. If not, then purchases from 3rd party developers might not work.