Como configurar Google Play Billing em um WordPress publicado como TWA na Google Play

Espero que você goste desse conteúdo. Mais conteúdo sobre esse tema visite meu canal no YouTube, clique aqui Autor: James Moro
  • Publicado em: Low Code
  • 22 visualizações

Um treinamento completo usando WordPress, TWA, Google Play Developer API e validação de compras no backend

Quando publicamos um site WordPress como aplicativo Android usando TWA, ou Trusted Web Activity, o app parece um aplicativo nativo para o usuário, mas na prática ele continua carregando uma experiência web.

Isso é muito poderoso, porque permite transformar um projeto WordPress em aplicativo publicado na Google Play. Porém, quando entramos na parte de compras dentro do app, precisamos tomar cuidado: a compra não pode depender apenas do JavaScript ou da resposta visual da tela de pagamento.

No caso de compras pela Google Play, existe um fluxo obrigatório: o usuário compra, o app recebe um token de compra, o backend precisa validar esse token na Google Play Developer API, liberar o acesso no sistema e confirmar a compra com acknowledge.

Se essa confirmação não for feita corretamente, a compra pode ser reembolsada automaticamente.

Neste treinamento, vamos usar como exemplo um WordPress publicado em um subdomínio fictício:

app.seudominio.com.br

E um app Android/TWA com um package name fictício:

br.com.seudominio.app.twa

1. Entendendo o problema

Imagine o seguinte cenário:

O usuário acessa o app pela Google Play, clica em comprar, o checkout abre normalmente, a compra é aprovada, mas depois de um tempo aparece reembolso.

Isso geralmente acontece porque a compra foi aprovada, mas não foi confirmada corretamente pelo backend.

No Google Play Billing, não basta receber uma resposta positiva do pagamento. O sistema precisa entender que:

  1. O usuário realmente comprou.
  2. O token da compra é válido.
  3. O produto comprado corresponde ao produto correto.
  4. O acesso foi liberado no seu sistema.
  5. A compra foi confirmada com acknowledge.

Se essa última etapa não acontecer, a Google pode entender que você não entregou o produto ao usuário. Como proteção, ela pode reembolsar automaticamente a compra.

2. Como funciona uma compra em TWA

Em um app nativo Android, normalmente usamos a biblioteca Google Play Billing dentro do código Android.

Mas em um app baseado em TWA, o fluxo é diferente. Como o app carrega uma experiência web, usamos APIs web compatíveis com Google Play Billing.

As principais peças são:

TWA
WordPress
JavaScript no front-end
Payment Request API
Digital Goods API
Google Play Developer API
Backend PHP
Conta de serviço do Google Cloud
Google Play Console

O fluxo ideal é:

Usuário logado no WordPress
        ↓
Usuário clica em comprar dentro da TWA
        ↓
JavaScript inicia o PaymentRequest com Google Play Billing
        ↓
Google Play processa a compra
        ↓
Front-end recebe o purchaseToken
        ↓
Front-end envia purchaseToken e productId para o WordPress
        ↓
WordPress valida a compra na Google Play Developer API
        ↓
WordPress libera o acesso para o usuário
        ↓
WordPress chama acknowledge
        ↓
Compra fica confirmada

O ponto principal é: a compra precisa terminar no backend, não apenas no front-end.

3. Por que o usuário precisa estar logado no WordPress?

Como o projeto é WordPress, o acesso comprado precisa ser associado a uma conta.

Por exemplo, se o usuário compra um recurso premium, o WordPress precisa saber para qual usuário liberar esse recurso.

Se o usuário não estiver logado, o backend não sabe para quem associar a compra.

Por isso, antes de iniciar o pagamento, o ideal é verificar:

if (!jrmData.isLoggedIn) {
  alert('Você precisa entrar na sua conta antes de comprar.');
  return;
}

Isso evita um problema grave: o usuário compra, mas o WordPress não consegue vincular a compra à conta dele.

4. O que é o package name?

O package name é o identificador técnico do aplicativo Android.

O nome público do app pode ser algo como:

Meu App Premium

Mas o identificador técnico costuma ser algo como:

br.com.seudominio.app.twa

É esse package name que precisa ser usado no backend ao conversar com a Google Play Developer API.

Se o package name estiver errado, a API pode não encontrar a compra ou pode retornar erro de permissão.

No WordPress, podemos salvar esse valor no wp-config.php:

define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

5. O que é a conta de serviço do Google Cloud?

A conta de serviço, ou Service Account, é uma identidade técnica usada pelo servidor.

Ela permite que o WordPress acesse a Google Play Developer API sem depender de login manual.

Essa conta de serviço precisa ter uma chave JSON. Esse arquivo JSON contém credenciais sensíveis e deve ficar somente no servidor.

Um exemplo de caminho seguro seria:

/home/seuusuario/credenciais/google-play-service-account.json

Esse caminho é melhor porque o arquivo fica fora da pasta pública do site.

Evite colocar a chave JSON dentro de:

public_html
wp-content
uploads
assets
themes
plugins

O ideal é manter o JSON fora de qualquer pasta acessível pelo navegador.

6. Onde fica o WordPress no servidor?

Em uma hospedagem comum, o WordPress pode estar em um caminho parecido com:

/home/seuusuario/app.seudominio.com.br/

O arquivo wp-config.php provavelmente estará em:

/home/seuusuario/app.seudominio.com.br/wp-config.php

Esse é o arquivo que deve receber as constantes de configuração.

Atenção: o caminho do site e o caminho do JSON são coisas diferentes.

O site pode estar aqui:

/home/seuusuario/app.seudominio.com.br/

E o JSON pode estar aqui:

/home/seuusuario/credenciais/google-play-service-account.json

Essa separação é boa, porque mantém a credencial fora da pasta pública do site.

7. Como configurar o wp-config.php

Abra o arquivo wp-config.php do WordPress.

No servidor, você pode usar:

nano /home/seuusuario/app.seudominio.com.br/wp-config.php

Antes da linha:

/* That's all, stop editing! Happy publishing. */

Adicione:

define('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON', '/home/seuusuario/credenciais/google-play-service-account.json');
define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

O resultado deve ficar parecido com:

define('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON', '/home/seuusuario/credenciais/google-play-service-account.json');
define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

/* That's all, stop editing! Happy publishing. */

Essas duas constantes passam a ser a fonte oficial da configuração.

O código PHP não deve ficar usando package name hardcoded espalhado pelo projeto.

8. Como testar se o JSON existe no servidor

Depois de configurar o wp-config.php, acesse o servidor via SSH e rode:

ls -la /home/seuusuario/credenciais/google-play-service-account.json

Se o arquivo existir, você verá algo parecido com:

-rw------- 1 seuusuario seuusuario 2345 Jun 21 13:00 /home/seuusuario/credenciais/google-play-service-account.json

Se aparecer “No such file or directory”, o caminho está errado ou o arquivo foi movido.

Também é possível procurar arquivos JSON com:

find /home/seuusuario -iname "*.json"

9. Permissões recomendadas para o JSON

O JSON contém credenciais sensíveis. Portanto, ele não deve ter permissão ampla.

Uma permissão mais restrita seria:

chmod 600 /home/seuusuario/credenciais/google-play-service-account.json

Se o PHP não conseguir ler o arquivo por causa da configuração da hospedagem, pode ser necessário testar:

chmod 640 /home/seuusuario/credenciais/google-play-service-account.json

O objetivo é permitir que o servidor leia o arquivo, mas impedir acesso público ou desnecessário.

Nunca use permissão 777 nesse arquivo.

10. Como o PHP deve validar essas constantes

No código do plugin ou tema responsável pela integração, o ideal é validar se as constantes existem.

Exemplo:

if (!defined('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON')) {
    error_log('Google Play Billing: constante JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON não definida.');
    return;
}

if (!defined('JRM_GOOGLE_PLAY_PACKAGE_NAME')) {
    error_log('Google Play Billing: constante JRM_GOOGLE_PLAY_PACKAGE_NAME não definida.');
    return;
}

Depois, o código deve verificar se o arquivo existe e se é legível:

$json_path = JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON;

if (!file_exists($json_path)) {
    error_log('Google Play Billing: arquivo JSON da service account não encontrado.');
    return;
}

if (!is_readable($json_path)) {
    error_log('Google Play Billing: arquivo JSON da service account não está legível pelo PHP.');
    return;
}

Importante: nunca imprima o conteúdo do JSON em tela, no console ou na resposta da API.

O máximo que o log deve dizer é se o arquivo existe ou não existe.

11. Configurando o Google Cloud

Agora precisamos preparar o Google Cloud.

O WordPress vai usar a Google Play Developer API. Para isso, é necessário ter:

Projeto no Google Cloud
Google Play Android Developer API ativada
Service Account criada
Arquivo JSON da Service Account

Passo 1: criar ou selecionar um projeto

Acesse o Google Cloud Console.

Crie um projeto com um nome fácil de identificar, por exemplo:

Google Play Billing - Meu App

Ou use um projeto existente.

Passo 2: ativar a API

No Google Cloud Console:

  1. Vá em “APIs e serviços”.
  2. Acesse “Biblioteca”.
  3. Pesquise por “Google Play Android Developer API”.
  4. Clique em ativar.

Essa é a API que o WordPress usará para consultar e confirmar compras.

Passo 3: criar uma Service Account

No Google Cloud:

  1. Vá em “IAM e administrador”.
  2. Acesse “Contas de serviço”.
  3. Clique em “Criar conta de serviço”.
  4. Dê um nome como:
wordpress-google-play-billing

Depois de criar, copie o e-mail da Service Account.

Ele será parecido com:

wordpress-google-play-billing@nome-do-projeto.iam.gserviceaccount.com

Esse e-mail precisa ser adicionado no Google Play Console.

Passo 4: criar chave JSON

Dentro da Service Account:

  1. Vá em “Chaves”.
  2. Clique em “Adicionar chave”.
  3. Escolha “Criar nova chave”.
  4. Selecione JSON.
  5. Baixe o arquivo.

Depois envie esse arquivo para o servidor, de preferência fora da pasta pública do site.

Exemplo:

/home/seuusuario/credenciais/google-play-service-account.json

12. Configurando permissões no Google Play Console

Agora precisamos autorizar essa Service Account dentro do Google Play Console.

No Play Console:

  1. Vá em “Usuários e permissões”.
  2. Clique em “Convidar novo usuário”.
  3. Cole o e-mail da Service Account.
  4. Selecione o app correto.
  5. Conceda as permissões necessárias.

As permissões mais importantes são relacionadas a dados financeiros e Purchases API.

Procure opções parecidas com:

View app information
View financial data
View financial data, orders, and cancellation survey responses
Manage orders and subscriptions

Dependendo do idioma do painel, os nomes podem aparecer traduzidos.

O ponto principal é: a Service Account precisa ter acesso à Purchases API. Sem isso, o backend pode receber erro de permissão ao tentar validar a compra.

Depois de salvar, pode levar algum tempo para as permissões propagarem.

13. Configurando os produtos no Play Console

Dentro do app no Google Play Console, confira se os produtos estão criados corretamente.

Vá em:

Monetização
Produtos no app

ou:

Monetização
Assinaturas

Verifique o ID do produto.

Exemplo:

premium_access
remove_ads
assinatura_mensal

Esse ID precisa ser exatamente igual ao productId usado no JavaScript e enviado ao backend.

Se no Play Console o produto se chama:

premium_access

mas no código está:

premium

a validação pode falhar.

14. Front-end: expondo dados do WordPress para o JavaScript

O JavaScript precisa saber:

  1. Qual endpoint REST chamar.
  2. Se o usuário está logado.
  3. Qual nonce REST enviar.

No WordPress, podemos usar wp_localize_script.

Exemplo:

function jrm_enqueue_billing_script() {
    wp_enqueue_script(
        'jrm-google-play-billing',
        get_stylesheet_directory_uri() . '/assets/js/google-play-billing.js',
        array('jquery'),
        '1.0.0',
        true
    );

    wp_localize_script('jrm-google-play-billing', 'jrmData', array(
        'restUrl'    => esc_url_raw(rest_url('google-play-billing/v1/confirmar-compra')),
        'nonce'      => wp_create_nonce('wp_rest'),
        'isLoggedIn' => is_user_logged_in(),
    ));
}
add_action('wp_enqueue_scripts', 'jrm_enqueue_billing_script');

Isso cria um objeto JavaScript chamado jrmData.

No navegador, ele terá algo parecido com:

jrmData = {
  restUrl: "https://app.seudominio.com.br/wp-json/google-play-billing/v1/confirmar-compra",
  nonce: "abc123",
  isLoggedIn: true
}

15. Por que usar X-WP-Nonce?

O WordPress REST API usa nonce para validar requisições autenticadas vindas do navegador.

Mesmo que o usuário esteja logado no WordPress, uma requisição JavaScript manual precisa enviar o nonce.

Sem isso, o WordPress pode tratar a chamada como se fosse de um visitante não logado.

Por isso, no JavaScript, precisamos enviar:

X-WP-Nonce

Exemplo com fetch:

fetch(jrmData.restUrl, {
  method: 'POST',
  credentials: 'same-origin',
  headers: {
    'Content-Type': 'application/json',
    'X-WP-Nonce': jrmData.nonce
  },
  body: JSON.stringify({
    purchaseToken: purchaseToken,
    productId: productId,
    productType: 'inapp'
  })
});

O detalhe credentials: 'same-origin' ajuda o navegador a enviar os cookies do WordPress junto com a requisição.

16. Criando o endpoint REST no WordPress

O backend precisa ter um endpoint para receber o token da compra.

Exemplo:

add_action('rest_api_init', function () {
    register_rest_route('google-play-billing/v1', '/confirmar-compra', array(
        'methods'  => 'POST',
        'callback' => 'jrm_confirmar_compra_google_play',
        'permission_callback' => function () {
            return is_user_logged_in();
        },
    ));
});

Esse endpoint ficaria disponível em:

https://app.seudominio.com.br/wp-json/google-play-billing/v1/confirmar-compra

A função permission_callback impede que visitantes não logados validem compras.

17. Validando entrada no endpoint

A função precisa receber os dados e validar:

function jrm_confirmar_compra_google_play(WP_REST_Request $request) {
    if (!is_user_logged_in()) {
        return new WP_Error(
            'jrm_user_not_logged_in',
            'Você precisa estar logado para verificar sua compra.',
            array('status' => 401)
        );
    }

    $user_id = get_current_user_id();

    $purchase_token = sanitize_text_field($request->get_param('purchaseToken'));
    $product_id = sanitize_text_field($request->get_param('productId'));
    $product_type = sanitize_text_field($request->get_param('productType'));

    if (empty($purchase_token) || empty($product_id)) {
        return new WP_Error(
            'jrm_missing_params',
            'purchaseToken e productId são obrigatórios.',
            array('status' => 400)
        );
    }

    if (!defined('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON') || !defined('JRM_GOOGLE_PLAY_PACKAGE_NAME')) {
        return new WP_Error(
            'jrm_missing_config',
            'Configuração do Google Play Billing ausente.',
            array('status' => 500)
        );
    }

    $json_path = JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON;

    if (!file_exists($json_path) || !is_readable($json_path)) {
        return new WP_Error(
            'jrm_json_not_readable',
            'Arquivo de credenciais do Google Play não encontrado ou não legível.',
            array('status' => 500)
        );
    }

    return rest_ensure_response(array(
        'success' => true,
        'message' => 'Configuração inicial validada.'
    ));
}

Esse exemplo ainda não faz a chamada real à Google Play Developer API, mas já mostra as validações básicas que precisam existir.

18. Validando a compra na Google Play Developer API

Depois de receber o purchaseToken, o backend precisa consultar a Google Play Developer API.

Para produto avulso, o endpoint conceitual é:

applications/{packageName}/purchases/products/{productId}/tokens/{token}

Para assinatura, o endpoint é diferente.

A validação precisa verificar pontos como:

packageName correto
productId correto
purchaseToken correto
estado da compra
se a compra já foi confirmada
se a compra pertence ao produto esperado

O package name usado deve vir da constante:

$package_name = JRM_GOOGLE_PLAY_PACKAGE_NAME;

Nunca deixe isso solto no código.

Evite algo assim:

$package_name = 'com.exemplo.app';

O correto é:

$package_name = JRM_GOOGLE_PLAY_PACKAGE_NAME;

19. Liberando o acesso no WordPress

Depois que a API confirma que a compra é válida, o WordPress pode liberar o acesso.

A forma mais simples é usar user_meta.

Exemplo:

update_user_meta($user_id, 'jrm_premium_access', 'yes');
update_user_meta($user_id, 'jrm_google_play_product_id', $product_id);
update_user_meta($user_id, 'jrm_google_play_purchase_token', $purchase_token);

Também é possível salvar:

update_user_meta($user_id, 'jrm_google_play_purchase_status', 'validated');
update_user_meta($user_id, 'jrm_google_play_purchase_date', current_time('mysql'));

Se o projeto crescer, pode ser melhor criar uma tabela própria para compras.

Mas para um fluxo inicial, user_meta pode resolver.

20. Chamando acknowledge

Depois que o acesso foi liberado, o backend precisa confirmar a compra com acknowledge.

Esse é o ponto que muitas integrações esquecem.

A lógica deve ser:

Compra válida?
        ↓
Sim
        ↓
Libera acesso no WordPress
        ↓
Chama acknowledge na Google Play Developer API
        ↓
Salva compra como confirmada

Não chame acknowledge antes de liberar o acesso.

A ordem correta é importante porque o acknowledge significa, na prática, que você recebeu a compra e entregou o direito ao usuário.

21. Evitando confirmar a mesma compra várias vezes

O backend deve verificar se aquela compra já foi processada.

Por exemplo:

$existing_token = get_user_meta($user_id, 'jrm_google_play_purchase_token', true);

if ($existing_token === $purchase_token) {
    return rest_ensure_response(array(
        'success' => true,
        'message' => 'Compra já validada anteriormente.'
    ));
}

Em um sistema mais completo, o ideal é salvar tokens em uma tabela própria, porque um usuário pode ter mais de uma compra ou assinatura.

22. Recuperação de compras existentes

Um bom app não deve depender apenas do momento exato da compra.

Imagine que:

O usuário compra
A internet cai
O app fecha
O celular trava
A chamada ao backend falha

Nesse caso, a compra pode ter sido aprovada, mas o backend não validou nem confirmou.

Por isso, quando o app abrir, o front-end deve consultar compras existentes usando a Digital Goods API.

A lógica é:

async function verificarComprasExistentes() {
  if (!window.getDigitalGoodsService) {
    return;
  }

  const service = await window.getDigitalGoodsService('https://play.google.com/billing');
  const purchases = await service.listPurchases();

  for (const purchase of purchases) {
    await fetch(jrmData.restUrl, {
      method: 'POST',
      credentials: 'same-origin',
      headers: {
        'Content-Type': 'application/json',
        'X-WP-Nonce': jrmData.nonce
      },
      body: JSON.stringify({
        purchaseToken: purchase.purchaseToken || purchase.token,
        productId: purchase.itemId,
        productType: 'inapp'
      })
    });
  }
}

Essa recuperação é importante para reduzir o risco de compras aprovadas ficarem sem confirmação.

23. Segurança: o que nunca deve ir para o front-end

Nunca coloque no JavaScript:

conteúdo do JSON da service account
client_email
private_key
caminho interno completo se não for necessário
tokens sensíveis do servidor
credenciais do Google Cloud

A Service Account deve ser usada somente pelo PHP.

O navegador deve lidar apenas com:

productId
purchaseToken recebido após compra
endpoint REST
nonce do WordPress
estado de login

24. Logs úteis para depuração

Durante o desenvolvimento, é útil criar logs.

Exemplo:

error_log('Google Play Billing: iniciando validação de compra.');
error_log('Google Play Billing: productId recebido: ' . $product_id);
error_log('Google Play Billing: usuário atual: ' . $user_id);

Mas nunca faça:

error_log(file_get_contents(JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON));

Também evite logar o token completo da compra.

Se precisar depurar, registre apenas parte dele:

error_log('Google Play Billing: token recebido prefixo: ' . substr($purchase_token, 0, 8));

25. Como testar se o endpoint REST está funcionando

Você pode acessar no navegador:

https://app.seudominio.com.br/wp-json/

Se a REST API estiver ativa, você verá uma resposta JSON do WordPress.

Depois, confira se o endpoint aparece:

https://app.seudominio.com.br/wp-json/google-play-billing/v1/confirmar-compra

Como o endpoint é POST e exige login, acessar diretamente pelo navegador pode retornar erro. Isso é normal.

O importante é que ele exista e responda de forma controlada.

26. Como testar se o WordPress está lendo o JSON

Você pode pedir para o código registrar temporariamente:

error_log('Google Play JSON existe? ' . (file_exists(JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON) ? 'sim' : 'não'));
error_log('Google Play JSON legível? ' . (is_readable(JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON) ? 'sim' : 'não'));

Depois teste e veja o log de erro do servidor.

Em hospedagem cPanel, o log pode estar em locais como:

error_log
logs
public_html/error_log
app.seudominio.com.br/error_log

Ou você pode procurar:

find /home/seuusuario -iname "error_log"

Depois de testar, remova os logs temporários.

27. Como testar compra em ambiente real

O ideal é testar usando usuário de teste da Google Play.

Checklist de teste:

[ ] App instalado pela Google Play
[ ] Usuário está logado no WordPress
[ ] Produto existe no Play Console
[ ] productId do código é igual ao productId do Play Console
[ ] Service Account tem permissão no Play Console
[ ] Google Play Android Developer API está ativada no Google Cloud
[ ] JSON está fora da pasta pública
[ ] wp-config.php tem as constantes corretas
[ ] Front-end envia X-WP-Nonce
[ ] Backend recebe purchaseToken
[ ] Backend valida a compra
[ ] Backend libera acesso
[ ] Backend chama acknowledge
[ ] Backend salva status da compra

Depois de comprar, confira:

Order Management no Play Console
Logs do WordPress
user_meta do usuário
Resposta do endpoint REST
Se houve acknowledge

28. Checklist final da configuração

Domínio do app

app.seudominio.com.br

Caminho provável do WordPress

/home/seuusuario/app.seudominio.com.br/

Caminho do wp-config.php

/home/seuusuario/app.seudominio.com.br/wp-config.php

Caminho da Service Account JSON

/home/seuusuario/credenciais/google-play-service-account.json

Package name do app

br.com.seudominio.app.twa

Constantes no wp-config.php

define('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON', '/home/seuusuario/credenciais/google-play-service-account.json');
define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

29. Erros comuns

Erro 1: JSON dentro da pasta pública

Errado:

/home/seuusuario/app.seudominio.com.br/wp-content/uploads/service-account.json

Certo:

/home/seuusuario/credenciais/google-play-service-account.json

Erro 2: package name errado

Errado:

define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'com.exemplo.app');

Certo:

define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

Erro 3: validar compra só no front-end

Errado:

Compra aprovada no JavaScript = liberar acesso

Certo:

Compra aprovada no JavaScript
        ↓
Enviar token ao backend
        ↓
Backend valida na Google
        ↓
Backend libera acesso
        ↓
Backend confirma com acknowledge

Erro 4: não enviar X-WP-Nonce

Se o nonce não for enviado, o WordPress pode tratar a requisição como não autenticada.

Correto:

headers: {
  'Content-Type': 'application/json',
  'X-WP-Nonce': jrmData.nonce
}

Erro 5: usuário comprar sem estar logado

Se o usuário não estiver logado, o WordPress não sabe onde liberar o acesso.

Antes da compra:

if (!jrmData.isLoggedIn) {
  alert('Você precisa entrar na sua conta antes de comprar.');
  return;
}

30. Conclusão

Integrar Google Play Billing em um WordPress publicado como TWA exige mais cuidado do que uma compra comum na web.

O ponto principal é entender que a compra passa por duas camadas:

Camada 1: Front-end
Abre o checkout e recebe o token da compra.

Camada 2: Backend
Valida o token, libera o acesso e confirma a compra.

Se a segunda camada não estiver completa, a compra pode ser aprovada inicialmente, mas depois acabar reembolsada.

Em um projeto real, a configuração central pode seguir este modelo:

define('JRM_GOOGLE_PLAY_SERVICE_ACCOUNT_JSON', '/home/seuusuario/credenciais/google-play-service-account.json');
define('JRM_GOOGLE_PLAY_PACKAGE_NAME', 'br.com.seudominio.app.twa');

Essas constantes devem ser usadas pelo backend PHP como fonte oficial para validar e confirmar compras.

O fluxo final correto é:

Usuário logado
        ↓
Compra na TWA
        ↓
Front-end recebe purchaseToken
        ↓
Front-end envia token ao WordPress com X-WP-Nonce
        ↓
WordPress valida na Google Play Developer API
        ↓
WordPress libera acesso
        ↓
WordPress chama acknowledge
        ↓
Compra confirmada

Quando esse fluxo está completo, a integração fica muito mais segura, organizada e reduz bastante o risco de reembolso automático por falta de confirmação.

Artigos Relacionados

Compartilhe este conteúdo:
Vídeos Sprint Codes
YouTube

Acesse o canal do
Sprint Codes no YouTube!

Acesse agora e tenha diariamente conteúdos gratuitos sobre um mundo de possibilidades com low-code e muita informação sobre tecnologia.

Acessar o canal
Vamos juntos fortalecer o Desenvolvimento de Aplicativos no Brasil? Conheça mais sobre a Sprint Codes 🚀
2024 © Sprint Codes - Especializados em aplicativos | Todos os direitos reservados.
Desenvolvido em WordPress