Estrutura de um pedido
A resposta da criação pública contém os seguintes campos principais:Status dos pedidos
Os principais estados do pedido são:
O fluxo mais comum é:
Fluxo de checkout
1
Cliente seleciona os produtos
O cliente escolhe os produtos e as variações desejadas e informa seus dados pessoais.
2
Sua aplicação cria o pedido
O frontend envia uma requisição para
POST /api/v1/orders/public, incluindo o header X-Store-ID, os dados do cliente e os identificadores dos produtos.3
A BukioPay valida o catálogo
A API consulta os produtos e as variações cadastradas, valida estoque e disponibilidade e calcula o valor final do pedido no servidor.
4
A API gera o pagamento PIX
A resposta contém
order.pix.qr_code, order.pix.copy_paste e order.pix.expires_at quando a cobrança PIX é criada com sucesso.5
Cliente realiza o pagamento
O cliente escaneia o QR Code ou utiliza o código Copia e Cola no aplicativo bancário.
6
Sua aplicação recebe a confirmação
Utilize o webhook
payment.paid como mecanismo principal para confirmar o pagamento e liberar o pedido.Criando um checkout público
O checkout público utiliza o seguinte endpoint:X-Store-ID.
Corpo da requisição
string
required
Nome completo do cliente.
string
required
E-mail válido do cliente.
string
Telefone do cliente.
string
CPF ou CNPJ do cliente. A API remove automaticamente caracteres de formatação.
array
required
Lista dos produtos incluídos no pedido. O pedido deve possuir pelo menos um item.
string
required
UUID do produto cadastrado na loja.
string
UUID da variação selecionada, quando o produto possuir variações.
number
required
Quantidade desejada. Deve ser maior que zero.
string
Método de pagamento. Para checkout PIX, envie
pix. Quando omitido, o padrão é PIX.string
Código de cupom que deverá ser aplicado ao pedido.
string
Código de atribuição de afiliado, quando aplicável.
string
Alternativa para enviar a chave de idempotência no corpo. O header
Idempotency-Key tem prioridade.Exemplo de requisição
Exemplo de resposta
Uma criação pública bem-sucedida retorna200 OK.
O campo
order.pix pode ser null quando não for possível confirmar a criação do pagamento. A resposta também pode incluir warning. Nesse caso, não crie outro pedido imediatamente usando uma chave diferente.Idempotência do checkout
Envie uma chave de idempotência em todas as criações:idempotencyKey no corpo, mas o header tem prioridade.
- A API retorna a chave efetiva no header
Idempotency-Key. - Um replay seguro preserva o mesmo pedido.
- Um replay é indicado por
Idempotency-Replayed: true. - Se a mesma chave for reutilizada com dados diferentes, a API retorna
409 Conflict. - Se o pedido ainda estiver sendo processado, a API pode retornar
409 ConflicteRetry-After. - Se a criação do PIX estiver incerta, a API retorna
PaymentCreationUnknowne não repete automaticamente o envio.
Exibindo o QR Code
Quandoorder.pix.qr_code contiver uma Data URL, ela poderá ser utilizada diretamente:
Confirmando o pagamento
Use o webhookpayment.paid como mecanismo principal para confirmar o pagamento.
O webhook informa a transição financeira em tempo real e deve ser processado de forma idempotente.
A consulta do pedido pode ser utilizada como fallback ou para reconciliação. Evite depender de polling contínuo quando os webhooks estiverem configurados.
Consultando um pedido autenticado
Para consultar os dados completos de um pedido pelo backend, utilize:transaction.verify.
O parâmetro :id aceita:
- UUID interno do pedido;
order_codede 18 caracteres.
Listando pedidos
Para listar os pedidos da loja autenticada, utilize:transaction.verify.
Filtros disponíveis:
Boas práticas
Nunca confie nos preços enviados pelo frontend
Nunca confie nos preços enviados pelo frontend
Envie apenas os identificadores dos produtos, das variações e as quantidades. A BukioPay consulta o catálogo e calcula os valores no servidor.
Use uma chave de idempotência
Use uma chave de idempotência
Gere uma
Idempotency-Key para cada tentativa lógica de checkout e reutilize a mesma chave em retries.Confirme o pagamento por webhook
Confirme o pagamento por webhook
Utilize
payment.paid como mecanismo principal de confirmação antes de entregar produtos ou liberar acessos.Não exponha sua API Key
Não exponha sua API Key
Utilize
POST /api/v1/orders/public no frontend com X-Store-ID. Endpoints autenticados e API Keys devem permanecer no backend.Não entregue o pedido apenas pelo retorno da criação
Não entregue o pedido apenas pelo retorno da criação
O retorno da criação confirma que o pedido foi registrado, não que o pagamento foi concluído. Aguarde o status
paid.Pronto para integrar pedidos na sua loja? Consulte a referência completa dos endpoints. Ver endpoints de Pedidos →
