PAYMENT-SIGNATURE e, em seguida, tenta novamente com a mesma solicitação.
A diferença é que o pagamento de pedidos pertence à API da plataforma e requer um token de conta; enquanto chamar diretamente a API de IA de x402.acedata.cloud pode usar apenas X402, sem precisar de um API Token.
Preparar o pedido
Acesse o console do Ace Data Cloud, selecione o pedido que precisa ser pago e registre o ID do pedido. Se você ainda não tiver um pedido, pode criar um pedido pendente de pagamento na página de planos. O preço do pedido é o exibido na página, e oamount na resposta X402 402 é a base final para a assinatura.
Criar token de conta
As solicitações de pagamento de pedidos exigem um token de conta. Abra a página de Token da plataforma e crie um token no formatoplatform-v1-....
Use nas solicitações subsequentes:
Acionar 402
Primeiro, envie uma solicitação semPAYMENT-SIGNATURE:
accepts:
x402Version é 2, network usa o identificador CAIP-2 e o campo de valor é amount.
Resultado da execução do programa ao criar um pedido de 10 Credits e acionar 402:
Os registros de transação abaixo são amostras históricas testadas sob a política antiga, e o valor e o hash da transação são mantidos como estavam. Novos pedidos X402 não têm mais desconto por método de pagamento; use o amount da resposta 402 desta vez como base para assinatura e pagamento.
- Após a criação bem-sucedida do pedido, o status é
Pending; neste momento, ainda não há pagamento on-chain. - A primeira solicitação
pay/não transportaPAYMENT-SIGNATURE, portanto retorna HTTP 402. acceptsfornece simultaneamente Baseexacte Solanaexact; este tutorial escolhe Base nas etapas seguintes.- O preço ao criar o pedido era
1.26; durante a política antiga de desconto de pagamento X402, o valor real de assinatura e liquidação era1.2USDC, correspondente a1200000atomic USDC.
resource aqui é um campo retornado pelo servidor e envolvido na assinatura; o cliente não deve reescrever por conta própria o protocolo, o caminho ou o ID do pedido nele.
Assinar e tentar novamente
O pagamento de pedidos pode reutilizar as funções de assinatura de baixo nível de@acedatacloud/x402-client ou acedatacloud-x402. Abaixo está um exemplo em TypeScript:
exact:
status 200indica que a interface de pagamento de pedidos da plataforma aceitou estaPAYMENT-SIGNATURE.has_x_payment_response Trueindica que o cabeçalho de resposta contém o reciboPAYMENT-RESPONSEcodificado em Base64.settle_header.success=Trueenetwork=baseindicam que o Facilitator concluiu o settlement na Base.- O status final do pedido é
Finished,pay_wayéX402, epay_idregistra o hash da transação on-chain. - O evento
Transferno BaseScan mostra que o endereço de pagamento transferiu1200000USDC atomic para o endereço de recebimento da plataforma, ou seja,1.2USDC.
Resposta de sucesso e recibo
Após o pagamento do pedido ser bem-sucedido, o corpo da resposta contém as informações do pedido. A plataforma também incluirá no cabeçalho de respostaPAYMENT-RESPONSE uma settlement response codificada em Base64, cujos campos comuns após a decodificação incluem:
Se você precisar fazer reconciliação, recomenda-se salvar simultaneamente o ID do pedido, o endereço da carteira pagadora,
transaction e o status final do pedido.
Observações
- O pagamento do pedido requer o token da conta da plataforma e não pode ser concluído apenas com a assinatura da carteira X402.
amountusa USDC atomic units,1200000representa1.2USDC.- Não monte manualmente o endereço de recebimento ou o endereço do ativo; use como referência o
acceptsna resposta 402. - Se a mesma
PAYMENT-SIGNATUREfor enviada repetidamente, o Facilitator aplicará proteção contra repetição com base no nonce.
Resposta de falha de pagamento
O primeiro HTTP 402 semPAYMENT-SIGNATURE é um desafio de pagamento normal e não representa uma falha de pagamento. Falhas de verificação ou liquidação após a assinatura ainda mantêm o error padrão em formato de string como fallback de compatibilidade, e retornam uma estrutura de erro estável em extensions.acedatacloud.paymentError:
code, e códigos desconhecidos devem recorrer à falha de pagamento genérica. charged é um campo de três estados: somente retornará false quando houver uma rejeição explícita antes da liquidação; a ausência do campo indica que o status da cobrança é desconhecido e não pode ser interpretada como “não cobrado”. Após o pedido atual entrar em Failed, não é possível tentar novamente o mesmo pedido; corrija o problema da carteira e crie um novo pedido.
Não registre nem envie a PAYMENT-SIGNATURE completa, a assinatura da carteira, o payload de autorização, os diagnósticos brutos do Facilitator ou as respostas RPC. Para investigação pelo suporte, apenas o ID do pedido e o code de erro público são necessários.
