Capacidade de pedido

• Nome do recurso: br.dev.bcp.shopping.order

Visão geral

Os pedidos representam transações confirmadas resultantes de uma finalização de compra bem-sucedida submissão. Eles fornecem um registro completo do que foi comprado, como será entregue e o que aconteceu desde a colocação do pedido.

Conceitos-chave

Os pedidos têm três componentes principais:

Itens de linha — o que foi comprado na finalização da compra:

• Inclui contagens de quantidade atuais (total, cumprido)
• Pode alterar pós-pedido (ex.: edições de pedidos, trocas); DEVE incluir todos os itens de linha que já existiram no pedido, independentemente de edições ou alterações

Atendimento — como os itens são entregues:

• Expectativas — promessas voltadas para o comprador sobre quando/como os itens chegarão
• Eventos (registro somente anexado) — o que realmente aconteceu (por exemplo, 👕 foi enviado)

Ajustes — eventos pós-pedido independentes do atendimento:

• Normalmente movimentos de dinheiro (reembolsos, devoluções, créditos, disputas, cancelamentos)
• Pode ser qualquer alteração pós-pedido
• Pode acontecer antes, durante ou depois do cumprimento
• As empresas DEVERÃO acrescentar novas entradas em vez de alterar as existentes; o livro razão somente anexado é o preferido. Empresas que não mantêm histórico de ajustes PODEM realizar atualizações locais de entradas existentes (por exemplo, um único ajuste return pode fazer a transição de pending para completed)

Modelo de dados

Itens de linha

Os itens de linha refletem o que foi comprado na finalização da compra e seu estado atual:

• Detalhes do item (produto, preço, quantidade encomendada)
• Contagens de quantidade e status de cumprimento

Cumprimento

O atendimento rastreia como os itens são entregues ao comprador.

Expectativas

Expectativas são agrupamentos de itens voltados para o comprador (por exemplo, "pacote 📦"). Eles representam:

• Quais itens estão agrupados
• Para onde eles estão indo (destination)
• Como estão sendo entregues (method_type)
• Quando chegarão (description, fulfillable_on)

As expectativas podem ser divididas, mescladas ou ajustadas após o pedido. Por exemplo:

• Agrupe tudo por data de entrega: "o que vem quando"
• Use uma única expectativa com um amplo intervalo de datas para flexibilidade
• O objetivo é definir as expectativas do comprador – para obter a melhor experiência do comprador

Eventos de Cumprimento

Eventos de atendimento são um registro apenas anexado que rastreia remessas físicas:

• Itens de linha de referência por ID e quantidade
• Incluir informações de rastreamento
• O tipo é um campo de string aberto – as empresas podem usar qualquer valor que faça sentido (exemplos comuns: processing, shipped, in_transit, delivered, failed_attempt, canceled, undeliverable, returned_to_sender)

Atribuição

As empresas PODEM exibir um instantâneo do checkout de origem attribution no pedido. Somente leitura no pedido – os agentes não escrevem order.attribution. Consulte Atribuição para contrato subjacente.

Ajustes

Ajustes são eventos pós-pedido que existem independentemente de cumprimento:

• O tipo é um campo de string aberto – as empresas podem usar qualquer valor que faça sentido (normalmente movimentos de dinheiro como refund, return, credit, price_adjustment, dispute, cancellation)
• Pode ser qualquer alteração pós-pedido
• Opcionalmente, vincule a itens de linha (ou ao nível do pedido para itens como reembolsos de frete)
• Quantidades e valores são assinados – negativo para reduções (devoluções, reembolsos), positivo para adições (trocas)
• Incluir detalhamento dos totais quando relevante
• Pode acontecer a qualquer momento, independentemente do status de cumprimento

Esquema

Pedido

Nome	Tipo	Obrigatório	Descrição
ucp	any	Sim	Metadados BCP para respostas de order. Não são necessários payment handlers após a compra.
id	string	Sim	Identificador único do pedido.
label	string	Não	Rótulo legível por humanos para identificar o pedido. DEVE ser fornecido apenas pela empresa.
checkout_id	string	Sim	ID do checkout associado para conciliação.
permalink_url	string	Sim	Permalink para acessar o pedido no site do lojista.
line_items	Array[Order Line Item]	Sim	Itens de linha representando o que foi comprado — podem mudar após o pedido por meio de edições ou trocas.
fulfillment	object	Sim	Dados de fulfillment: as expectativas do comprador e o que de fato ocorreu.
adjustments	Array[Adjustment]	Não	Eventos pós-pedido (reembolsos, devoluções, créditos, disputas, cancelamentos, etc.) que existem independentemente do fulfillment.
currency	string	Sim	Código de moeda ISO 4217. DEVE corresponder à moeda da sessão de checkout de origem.
totals	Totals	Sim	Diferentes totais do pedido.
messages	Array[Message]	Não	Mensagens de resultado da empresa (erros, avisos, informativas). Presentes quando a empresa precisa comunicar status ou problemas à plataforma.
attribution	Attribution	Não	Snapshot da atribuição associada ao checkout de origem. Somente leitura no pedido.

Item de linha do pedido

Os itens de linha refletem o que foi comprado na finalização da compra e seu estado atual.

Nome	Tipo	Obrigatório	Descrição
id	string	Sim	Identificador do item de linha.
item	Item	Sim	Dados do produto (id, title, price, image_url).
quantity	object	Sim	Rastreamento de quantidade para o item de linha.
totals	Array[Total]	Sim	Detalhamento dos totais do item de linha.
status	string	Sim	Status derivado: removed se quantity.total == 0, fulfilled se quantity.total > 0 e quantity.fulfilled == quantity.total, partial se quantity.total > 0 e quantity.fulfilled > 0, caso contrário processing. Enum: processing, partial, fulfilled, removed
parent_id	string	Não	Identificador do item de linha pai para quaisquer estruturas aninhadas.

Estrutura quantitativa:

{
  "original": 3,   // Quantity from the original checkout
  "total": 3,      // Current total (may differ after edits/exchanges)
  "fulfilled": 2   // What has been fulfilled
}

Derivação de status:

if (total == 0) → "removed"
else if (fulfilled == total) → "fulfilled"
else if (fulfilled > 0) → "partial"
else → "processing"

Expectativa

As expectativas são agrupamentos voltados para o comprador que representam quando/como os itens serão entregue. Eles representam a promessa atual ao comprador e podem ser pós-ordem dividida, mesclada ou ajustada.

Nome	Tipo	Obrigatório	Descrição
id	string	Sim	Identificador da expectativa.
line_items	Array[object]	Sim	Quais itens de linha e quantidades estão nesta expectativa.
method_type	string	Sim	Tipo de método de entrega (shipping, pickup, digital). Enum: shipping, pickup, digital
destination	Postal Address	Sim	Endereço de destino da entrega.
description	string	Não	Descrição de entrega legível por humanos (ex.: 'Chega em 5-8 dias úteis').
fulfillable_on	string	Não	Quando esta expectativa pode ser cumprida: 'now' ou timestamp ISO 8601 para data futura (backorder, pré-venda).

Evento de Cumprimento

Os eventos são registros somente anexados que rastreiam remessas reais. O campo type é uma cadeia aberta - as empresas podem usar quaisquer valores que façam sentido para seus processo de cumprimento.

Nome	Tipo	Obrigatório	Descrição
id	string	Sim	Identificador do evento de fulfillment.
occurred_at	string	Sim	Timestamp RFC 3339 de quando este evento de fulfillment ocorreu.
type	string	Sim	Tipo de evento de fulfillment. Valores comuns incluem: processing (preparando para envio), shipped (entregue à transportadora), in_transit (na rede de entrega), delivered (recebido pelo buyer), failed_attempt (tentativa de entrega falhou), canceled (fulfillment cancelado), undeliverable (não pode ser entregue), returned_to_sender (devolvido ao merchant).
line_items	Array[object]	Sim	Quais itens de linha e quantidades são cumpridos neste evento.
tracking_number	string	Não	Número de rastreamento da transportadora (obrigatório se type != processing).
tracking_url	string	Não	URL para rastrear este envio (obrigatório se type != processing).
carrier	string	Não	Nome da transportadora (ex.: 'Correios', 'Jadlog').
description	string	Não	Descrição legível por humanos do status do envio ou informação de entrega (ex.: 'Entregue na porta da frente', 'Saiu para entrega').

Exemplos: processing, shipped, in_transit, delivered, failed_attempt, canceled, undeliverable, returned_to_sender, etc.

Ajuste

Os ajustes são eventos polimórficos que existem independentemente da realização. O campo type é uma string aberta - as empresas podem usar qualquer valor que faça sentido para eles.

Nome	Tipo	Obrigatório	Descrição
id	string	Sim	Identificador do evento de ajuste.
type	string	Sim	Tipo de ajuste (string aberta). Normalmente relacionado a dinheiro, como: refund, return, credit, price_adjustment, dispute, cancellation. Pode ser qualquer valor que faça sentido para a empresa do merchant.
occurred_at	string	Sim	Timestamp RFC 3339 de quando este ajuste ocorreu.
status	string	Sim	Status do ajuste. Enum: pending, completed, failed
line_items	Array[object]	Não	Quais itens de linha e quantidades são afetados (opcional).
totals	Array[Total]	Não	Detalhamento dos totais do ajuste. Valores com sinal - negativos para dinheiro devolvido ao buyer (reembolsos, créditos), positivos para cobranças adicionais (trocas).
description	string	Não	Motivo ou descrição legível por humanos (ex.: 'Item defeituoso', 'Solicitado pelo cliente').

Exemplos: refund, return, credit, price_adjustment, dispute, cancellation, etc.

Exemplo

{
  "ucp": {
    "version": "2026-07-28",
    "capabilities": {
      "br.dev.bcp.shopping.order": [{"version": "2026-07-28"}]
    }
  },
  "id": "order_abc123",
  "checkout_id": "checkout_xyz789",
  "permalink_url": "https://business.example.com/orders/abc123",
  "currency": "BRL",
  "line_items": [
    {
      "id": "li_shoes",
      "item": { "id": "prod_shoes", "title": "Running Shoes", "price": 3000 },
      "quantity": { "original": 3, "total": 3, "fulfilled": 3 },
      "totals": [
        {"type": "subtotal", "amount": 9000},
        {"type": "total", "amount": 9000}
      ],
      "status": "fulfilled"
    },
    {
      "id": "li_shirts",
      "item": { "id": "prod_shirts", "title": "Cotton T-Shirt", "price": 2000 },
      "quantity": { "original": 2, "total": 2, "fulfilled": 0 },
      "totals": [
        {"type": "subtotal", "amount": 4000},
        {"type": "total", "amount": 4000}
      ],
      "status": "processing"
    }
  ],
  "fulfillment": {
    "expectations": [
      {
        "id": "exp_1",
        "line_items": [{ "id": "li_shoes", "quantity": 3 }],
        "method_type": "shipping",
        "destination": {
          "street_address": "Rua das Flores, 123",
          "address_locality": "São Paulo",
          "address_region": "SP",
          "address_country": "BR",
          "postal_code": "01310-100"
        },
        "description": "Chega em 2 a 3 dias úteis",
        "fulfillable_on": "now"
      },
      {
        "id": "exp_2",
        "line_items": [{ "id": "li_shirts", "quantity": 2 }],
        "method_type": "shipping",
        "destination": {
          "street_address": "Rua das Flores, 123",
          "address_locality": "São Paulo",
          "address_region": "SP",
          "address_country": "BR",
          "postal_code": "01310-100"
        },
        "description": "Em espera - envio em 15 de janeiro, chega em 7 a 10 dias",
        "fulfillable_on": "2025-01-15T00:00:00Z"
      }
    ],
    "events": [
      {
        "id": "evt_1",
        "occurred_at": "2025-01-08T10:30:00Z",
        "type": "delivered",
        "line_items": [{ "id": "li_shoes", "quantity": 3 }],
        "tracking_number": "BR123456789BR",
        "tracking_url": "https://rastreamento.correios.com.br/app/index.php?objetos=BR123456789BR",
        "description": "Entregue na portaria"
      }
    ]
  },
  "adjustments": [
    {
      "id": "adj_1",
      "type": "refund",
      "occurred_at": "2025-01-10T14:30:00Z",
      "status": "completed",
      "line_items": [{ "id": "li_shoes", "quantity": -1 }],
      "totals": [
        { "type": "total", "amount": -3000 }
      ],
      "description": "Item com defeito"
    }
  ],
  "totals": [
    { "type": "subtotal", "amount": 13000 },
    { "type": "fulfillment", "amount": 1200 },
    { "type": "tax", "amount": 1142 },
    { "type": "total", "amount": 15342 }
  ]
}

Escopos

O recurso Order define os seguintes escopos conhecidos para acesso autenticado pelo usuário:

Escopo	Descrição
br.dev.bcp.shopping.order:read	Acesso de leitura aos pedidos do usuário — Obtenha pedidos nos recursos pertencentes ao usuário autenticado.
br.dev.bcp.shopping.order:manage	Operações pós-compra nos pedidos do usuário — cancelamento, devoluções e outras modificações.

Declaração de escopo, derivação e regras para estender este conjunto com escopos personalizados são definidos em Vinculação de identidade — Escopos.

Operações

A entidade do pedido é um instantâneo do estado atual: o estado mais recente do pedido no momento da recuperação ou entrega. As empresas DEVEM retornar a entidade completa do pedido em cada resposta. O mesmo esquema é usado para recuperação síncrona (esta seção) e entrega de evento assíncrono (veja Eventos).

O permalink_url é a referência oficial para a experiência completa do pedido — cronograma, operações pós-compra, devoluções. A API fornece acesso programático ao estado atual para casos de uso conversacionais e operacionais.

Operação	Método	Ponto final	Descrição
Obter pedido	GET	/orders/{id}	A plataforma recupera o estado atual do pedido.

Para obter detalhes específicos do transporte, consulte Ligação REST (não incluída nesta versão do BCP) e Vinculação MCP

Obter pedido

Retorna o instantâneo do estado atual de um pedido.

Autorização

A empresa DEVE autenticar as solicitações de dados do pedido antes de retornar um resposta, usando qualquer mecanismo BCP compatível - chaves de API, OAuth 2.0, mútuo TLS ou assinaturas de mensagens HTTP (consulte Identidade e Autenticação (não incluídas nesta versão do BCP)). O O método de autenticação determina quais pedidos são acessíveis ao chamador:

Autenticação	Pedidos acessíveis
Credenciais da plataforma	Pedidos originados pela plataforma
Autorização do comprador	Pedidos de propriedade do comprador, sujeitos aos escopos OAuth concedidos

Credenciais da plataforma (chave de API, assinaturas, credenciais do cliente OAuth) - as empresas PODEM permitir o acesso para pedidos originados pela plataforma. O plataforma forneceu informações do comprador e de pagamento durante o fluxo de checkout, observou a confirmação do pedido e está recuperando o estado mais recente de um pedido para o qual já tem contexto.

Autorização do comprador - a plataforma obtém autorização do comprador via Identity Linking com os escopos necessários, ou um mecanismo semelhante. Isso concede acesso aos pedidos do comprador, independentemente de qual plataforma os originou.

As empresas PODEM definir políticas de acesso adicionais (por exemplo, parceiro confiável acordos), impor restrições de disponibilidade de dados (por exemplo, retenção janelas, eliminação regulatória) e omitir ou redigir campos opcionais da resposta com base no contexto, política comercial ou outros requisitos - independentemente de autorização.

Respostas de erro

Quando a empresa não consegue devolver um pedido, a resposta retorna um erro que inclui uma matriz messages descrevendo o resultado:

Pedido não encontrado:

{
  "ucp": {
    "version": "2026-07-28",
    "status": "error",
    "capabilities": {
      "br.dev.bcp.shopping.order": [{"version": "2026-07-28"}]
    }
  },
  "messages": [
    {
      "type": "error",
      "code": "not_found",
      "severity": "unrecoverable",
      "content": "Order not found."
    }
  ]
}

Não autorizado:

{
  "ucp": {
    "version": "2026-07-28",
    "status": "error",
    "capabilities": {
      "br.dev.bcp.shopping.order": [{"version": "2026-07-28"}]
    }
  },
  "messages": [
    {
      "type": "error",
      "code": "unauthorized",
      "severity": "unrecoverable",
      "content": "Not authorized to access this order."
    }
  ]
}

Diretrizes

Plataforma:

• DEVE incluir o cabeçalho BCP-Agent com URL do perfil em todas as solicitações
• DEVERIA contar com webhooks (consulte Eventos) como canal principal de atualização de pedidos e usar Obter Pedido para reconciliação ou recuperação sob demanda
• DEVE tratar os dados do pedido como efêmeros e descartá-los quando não forem mais necessários para fluxos de comércio ativos

Negócios:

• DEVE autenticar as solicitações de dados do pedido antes de retornar uma resposta (veja Autorização)

Eventos

As empresas enviam atualizações do ciclo de vida dos pedidos para a plataforma por meio de webhooks. A carga útil é o mesmo instantâneo do estado atual descrito em Operações — a entidade completa do pedido.

Evento	Método	Ponto final	Descrição
Webhook de evento de pedido	POST	URL fornecido pela plataforma	A empresa envia eventos do ciclo de vida do pedido para a plataforma.

Webhook de evento de pedido

As empresas enviam eventos de pedido via POST para uma URL de webhook fornecida pela plataforma durante a integração do parceiro. O formato da URL é específico da plataforma.

Os cabeçalhos seguem Webhooks padrão; exceto para assinatura de solicitação, que segue RFC 9421. Consulte Assinaturas de mensagens para obter mais detalhes.

Cabeçalhos obrigatórios:

Cabeçalho	Descrição
Webhook-Timestamp	Carimbo de data e hora da ocorrência do evento (unix)
Webhook-Id	Identificador único do evento

A descrição do serviço OpenAPI para webhooks de pedidos não está publicada nesta versão do BCP. O corpo do webhook usa o envelope de resposta do pedido e os mesmos requisitos de assinatura descritos nesta seção.

Configuração de URL do webhook

A plataforma fornece seu URL de webhook no campo config do recurso de pedido durante a negociação de capacidade. A empresa descobre esse URL no perfil da plataforma e o utiliza para enviar eventos do ciclo de vida do pedido.

Configuração da capability de order da plataforma.

Nome	Tipo	Obrigatório	Descrição
webhook_url	string	Sim	URL para onde o lojista envia eventos do ciclo de vida do pedido (webhooks).

Exemplo:

{
  "br.dev.bcp.shopping.order": [
    {
      "version": "2026-07-28",
      "spec": "https://bcp.dev.br/draft/specification/order",
      "schema": "https://bcp.dev.br/draft/schemas/shopping/order.json",
      "config": {
        "webhook_url": "https://platform.example.com/webhooks/bcp/orders"
      }
    }
  ]
}

Verificação de assinatura de webhook

As cargas úteis do webhook DEVEM ser assinadas pela empresa e verificadas pela plataforma para garantir autenticidade e integridade. As assinaturas seguem a especificação de Assinaturas de mensagens usando a ligação REST (RFC 9421).

Cabeçalhos obrigatórios:

Cabeçalho	Descrição
BCP-Agent	URL do perfil comercial (Dicionário RFC 8941)
Signature-Input	Descreve componentes assinados
Signature	Contém o valor da assinatura
Content-Digest	Resumo corporal (RFC 9530)

Exemplo de solicitação de webhook:

POST /webhooks/bcp/orders HTTP/1.1
Host: platform.example.com
Content-Type: application/json
BCP-Agent: profile="https://merchant.example/.well-known/bcp"
Content-Digest: sha-256=:X48E9q...:
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest" "content-type");keyid="merchant-2026"
Signature: sig1=:MEUCIQDTxNq8h7LGHpvVZQp1iHkFp9+3N8Mxk2zH1wK4YuVN8w...:

{"id":"order_abc123","event_id":"evt_123","created_time":"2026-01-15T12:00:00Z",...}

Assinatura (Negócios)

1. Calcule o resumo SHA-256 do corpo da solicitação bruta e defina o cabeçalho Content-Digest
2. Construa a base de assinatura de acordo com RFC 9421
3. Assine usando uma chave de keys no perfil BCP da empresa
4. Defina os cabeçalhos Signature-Input e Signature

Consulte Assinaturas de mensagens - Assinatura de solicitação REST para algoritmo completo.

Verificação (plataforma)

Autenticação (verificação de assinatura):

1. Analise Signature-Input para extrair keyid e componentes assinados
2. Obtenha o perfil BCP da empresa em /.well-known/bcp (cache conforme apropriado)
3. Localize a chave em keys com kid correspondente
4. Verifique se Content-Digest corresponde a SHA-256 do corpo bruto
5. Reconstrua a base de assinatura e verifique a assinatura

Consulte Assinaturas de mensagens - Verificação de solicitação REST para algoritmo completo.

Autorização (propriedade do pedido):

Depois de verificar a assinatura, a plataforma DEVE confirmar que o signatário está autorizado a enviar eventos para o pedido referenciado:

1. Extraia o ID do pedido da carga útil do webhook
2. Verifique se o pedido foi criado com esta empresa (o URL do perfil corresponde)
3. Rejeite webhooks em que o perfil do signatário não corresponda ao negócio do pedido

Isso evita que uma empresa mal-intencionada envie eventos falsos para pedidos de outro negócio, mesmo com uma assinatura válida.

Rotação de chaves

Consulte Assinaturas de mensagens - rotação de chaves para procedimentos de rotação de chaves com tempo de inatividade zero.

Diretrizes

Plataforma:

• DEVE responder rapidamente com um código de status HTTP 2xx para confirmar o recebimento do webhook; processar os eventos de forma assíncrona após responder

Negócios:

• DEVE incluir o cabeçalho BCP-Agent com URL do perfil para identificação do signatário
• DEVE assinar todas as cargas úteis do webhook de acordo com a especificação de Assinaturas de mensagens, usando os cabeçalhos RFC 9421 (Signature, Signature-Input, Content-Digest)
• DEVE enviar o evento "Pedido criado" com a entidade do pedido totalmente preenchida
• DEVE enviar a entidade completa do pedido nas atualizações (não deltas incrementais)
• DEVE tentar novamente entregas de webhook com falha

Entidades

Item

Nome	Tipo	Obrigatório	Descrição
id	string	Sim	O identificador do produto, muitas vezes o SKU, necessário para resolver os detalhes do produto associados a este item de linha. Deveria ser reconhecido tanto pela Plataforma quanto pelo Negócio.
title	string	Sim	Título do produto.
price	Amount	Sim	Preço unitário em unidades menores conforme ISO 4217.
image_url	string	Não	URI da imagem do produto.

Endereço postal

Nome	Tipo	Obrigatório	Descrição
extended_address	string	Não	Um complemento de endereço, como número de apartamento, A/C ou nome alternativo.
street_address	string	Não	O logradouro.
address_locality	string	Não	A localidade em que o logradouro está, e que está na região. Por exemplo, São Paulo.
address_region	string	Não	A região em que a localidade está, e que está no país. Obrigatório para países aplicáveis (por exemplo, estado no BR, província no CA). Por exemplo, São Paulo ou outra divisão administrativa de primeiro nível apropriada.
address_country	string	Não	O país. RECOMENDADO estar no formato ISO 3166-1 alpha-2 de 2 letras, por exemplo "BR". Para compatibilidade retroativa, também PODE ser usado um código de país ISO 3166-1 alpha-3 de 3 letras, como "BRA", ou o nome completo do país, como "Brasil".
postal_code	string	Não	O código postal (CEP). Por exemplo, 01310-100.
first_name	string	Não	Opcional. Nome do contato associado ao endereço.
last_name	string	Não	Opcional. Sobrenome do contato associado ao endereço.
phone_number	string	Não	Opcional. Número de telefone do contato associado ao endereço.

Resposta

Referência de capability em respostas. Apenas name/version são necessários para confirmar as capabilities ativas.

Nome	Tipo	Obrigatório	Descrição
version	string	Sim	Versão da entidade no formato YYYY-MM-DD.
spec	string	Não	URL para o documento de especificação legível por humanos.
schema	string	Não	URL para o JSON Schema que define a estrutura e os payloads desta entidade.
id	string	Não	Identificador único para esta instância de entidade. Usado para desambiguar quando existem múltiplas instâncias.
config	object	Não	Configuração específica da entidade. Estrutura definida pelo schema de cada entidade.
extends	OneOf[string, array]	Não	Capability(s) pai que esta estende. Presente para extensões, ausente para capabilities raiz. Use um array para extensões com múltiplos pais.

Total

Nome	Tipo	Obrigatório	Descrição
type	string	Sim	Categoria de custo. Valores conhecidos: subtotal, items_discount, discount, fulfillment, tax, fee, total. As empresas PODEM usar valores adicionais.
display_text	string	Não	Texto a exibir junto ao valor. Deveria refletir o método apropriado (por exemplo, 'Frete', 'Entrega').
amount	Signed Amount	Sim	Valor monetário na unidade menor da moeda, conforme definido pela ISO 4217. Consulte o expoente da moeda para determinar a razão entre unidade menor e maior (por exemplo, 2 para BRL, 2 para USD, 0 para JPY, 3 para KWD). Pode ser negativo — o sinal é intrínseco ao valor (por exemplo, descontos são negativos, cobranças são positivas).

Esquema de pedido de resposta BCP

Metadados BCP para respostas de order. Não são necessários payment handlers após a compra.

Nome	Tipo	Obrigatório	Descrição
version	string	Sim	Versão BCP no formato YYYY-MM-DD.
status	string	Não	Status em nível de aplicação da operação BCP. Enum: success, error
services	object	Não	Registro de serviços indexado por reverse-domain name.
capabilities	object	Não	Registro de capabilities indexado por reverse-domain name.
payment_handlers	object	Não	Registro de payment handlers indexado por reverse-domain name.
capabilities	any	Não