Purchase validation - Android

Each purchase should be validated before awarding it to the end-user. This assists in preventing unauthorized purchases and ensures the integrity of your in-app economy. Validating purchases is a critical security measure to prevent fraud, protect your revenue, and ensure fair user experiences.

Essentially, that are two distinct validation approaches readily available.

Server-side Validation

The most secure and reliable way to validate purchases is by using server-to-server (S2S) communication, with the client completely removed from the validation process. This minimizes security risks and ensures that entitlements are only granted based on verified data received directly from Xsolla.

With Xsolla, server-side validation is implemented through a webhook-based model:

• Once a user completes a purchase through your app, Xsolla services automatically trigger a webhook event to your backend.
• This webhook contains all the necessary purchase data, including the Xsolla order ID, enabling your server to validate and process the purchase asynchronously.
• Your backend can then use this data to update the user’s entitlements, balance, inventory, etc., without requiring any additional input from the client.

This flow ensures that the client has no role in deciding the outcome of a purchase — all validation logic lives on the server, using trusted data that originates from Xsolla itself.

tip

For more information about how webhooks work, see our Webhooks guide.

How does this compare to Google Play Billing?

This table provides a quick-glance comparison between Xsolla’s webhook-based server-side validation approach and Google Play Billing’s API-driven validation. While both are designed to assure the legitimacy of purchases, they operate through fundamentally different infrastructures and workflows. Notably, Xsolla does not use or abstract Google Play Developer APIs; instead, it provides an independent validation mechanism through webhooks.

Feature/Aspect	Xsolla Mobile SDK	Google Play Billing
Validation Flow	Webhook-driven: Xsolla services send a notification to your backend when a purchase completes. Your backend then validates and processes the order.	API-driven: Your backend polls or queries the Google Play Developer API using a purchaseToken received from the client to verify purchase authenticity.
Primary Identifier	Xsolla order ID	Google Play purchaseToken
Verification Authority	Xsolla's backend infrastructure and your own server logic	Google Play Developer API (purchases.products:get, purchases.subscriptionsv2:get, etc.)
Backend Integration Pattern	Reactive: Webhook-based model automatically pushes purchase data to your backend.	Polling or request-based: Your server must pull data from Google's APIs after receiving a purchaseToken from the client.
Asynchronous Handling	✅ Yes. Webhooks trigger upon purchase completion, enabling early or background processing.	⚠️ Possible, but typically requires polling or client-to-server relay before querying Google.
Security Handling	Simplified. Xsolla ensures validation before triggering webhook to your backend. You validate order ID and fulfill the order accordingly.	Complex. Your backend must securely handle API tokens, verify signatures, and respond to purchase states appropriately.
Integration Complexity	Lower — No need to manage credential scopes or external billing endpoints. Xsolla manages purchase flow and signals your backend.	Higher — Requires OAuth, service account setup, token lifecycle management, and granular error handling.

Client-side Validation

Provides means of validating a purchase on the user's device without a need for a backend (server). While it's better than nothing, it has inherent drawbacks: anything that runs on the client can potentially be exploited. This approach offers a rudimentary level of validation but is generally not recommended for critical applications due to its inherent security vulnerabilities.

When initializing a BillingClient, extend the onPurchasesUpdated callback of PurchasesUpdatedListener with the code below to enable a rudimentary (non-secure) purchase validation on the client:

final PurchasesUpdatedListener purchasesUpdatedListener = new PurchasesUpdatedListener() {
    @Override
    public void onPurchasesUpdated(
        @NonNull final BillingResult billingResult, @Nullable final List<Purchase> purchases
    ) {
        if (billingResult.isSuccess() && purchases != null) {
            // Validate and consume purchases one by one.
            for (int i = 0; i < purchases.size(); ++i) {
                final ValidateParams validateParams = ValidateParams.newBuilder()
                    .setPurchaseToken(purchases.get(i).getPurchaseToken())
                    .build();

                // This `validateAsync` method is part of the Xsolla Mobile SDK.
                // It performs a client-side network call to Xsolla's services for validation.
                // For developers coming from GPB, this serves a similar *purpose* to how you
                // might send a `purchaseToken` from the client to your *own* backend for validation,
                // but here, Xsolla's services act as that immediate validation point.
                mBillingClient.validateAsync(validateParams, new ValidateResponseListener() {
                    @Override
                    public void onValidateResponse(
                        @NonNull final BillingResult billingResult, @Nullable final String purchaseToken
                    ) {
                        // Make sure validation of the purchase was a success..
                        if (billingResult.isSuccess() && !TextUtils.isEmpty(purchaseToken)) {
                            // Prepare consumption parameters based on the purchase
                            // token received with the validation response.
                            final ConsumeParams consumeParams = ConsumeParams.newBuilder()
                                .setPurchaseToken(purchaseToken)
                                .build();

                            // This `consumeAsync` method is part of the Google Play Billing Library.
                            // It marks the purchase as consumed in Google Play's system.
                            // This part of the flow is identical to a pure GPB implementation.
                            mBillingClient.consumeAsync(consumeParams,
                                // TODO: Handle consumption success/failure.
                                // After successful consumption, grant entitlement to the user.
                                // For non-consumables and subscriptions, use acknowledgePurchase() instead of consumeAsync().
                            );
                        } else {
                            // Purchase validation has failed on the client-side.
                            // Handle error, do not grant entitlement.
                        }
                    }
                });
            }
        } else {
            // An error occurred, while trying to update the purchases.
            // This could be due to BillingClient connection issues or a user cancellation.
            // Handle error appropriately, do not grant entitlement.
        }
    }
}

How does this compare to Google Play Billing?

The Xsolla Mobile SDK follows a structure similar to Google Play Billing, which helps streamline development and simplifies adoption for those familiar with GPB. The table below outlines how common validation and fulfillment flows compare between the two:

Feature	Xsolla Mobile SDK	Google Play Billing
Validation	validateAsync(...) – sends purchaseToken to Xsolla services for basic validation	No built-in validation; purchaseToken must be sent manually to your backend
Consumption & Entitlement	consumeAsync(...) – called after validation to mark the purchase and unlock content	consumeAsync(...) – called after custom backend validation to complete the flow

Conclusion and Recommendations

The Xsolla Mobile SDK supports both client-side and server-side purchase validation flows to accommodate a wide range of application needs and developer workflows. Each approach comes with trade-offs in terms of security, complexity, and integration effort.

For production environments, especially where real monetary value or access to premium content is involved, server-side validation is the strongly recommended method. It ensures that all entitlements are granted based on verified purchase data received directly through Xsolla's secure webhook system, with no reliance on data provided by the client. This significantly reduces the risk of fraud or tampering.

Client-side validation, while faster to implement and sufficient for low-risk use cases, should be treated as a lightweight solution. It involves making validation requests from the device directly to Xsolla's services and can be bypassed if used in isolation. This method may be appropriate for prototypes or apps offering non-critical, low-value items.

info

The Xsolla Mobile SDK provides flexible validation options to help developers start quickly and scale securely. For best results, adopt the server-side webhook-based validation as your primary mechanism for managing purchase authenticity and entitlement fulfillment.