Migrando da v1 - 4SeletPay

A v2 não é uma cópia da v1 com outro prefixo. Autenticação, formato de resposta, valores e nomes de campos mudaram. Use esta página como guia de migração.

Principais diferenças

Tema	API v1	API v2
Autenticação	Token de login (`POST /v1/login`) + header `account`	Chave de API no `Authorization`, sem header `account`
Resposta de sucesso	Envelope `{ "mensagem", "erro", "data", ... }`	Objeto plano, com o campo `object` indicando o tipo
Resposta de erro	Envelope `{ "mensagem", "erro": true, "mensagenserro", ... }`	`{ "error": { "type", "code", "message" } }` — veja Erros
Valores	Reais com decimais (`97.90`)	Centavos inteiros (`9790`)
Meios por compra	Um meio de pagamento por cobrança	Um pedido com vários pagamentos (ex.: dois cartões, cartão + PIX)
Cliente	`client`	`customer`
Tipo de pagamento	`CreditCard`, `PIX`	`card`, `pix`
Dados do cartão	`number`, `name`, `month`, `year`, `security_code`	`number`, `holder_name`, `exp_month`, `exp_year`, `cvc`
Cartão salvo	`payment.card.card_token`	`card.token` (o `id` do cartão)
Split	Configuração de split da v1	Lista `split` por pagamento, com `receiver_code` e `amount` em centavos
Pular análise de fraude	`skip_fraud_analysis` e `is_upsell`	`fraud_analysis: { "skip": true, "reason": "..." }`
Intervalo da assinatura	`interval` em dias	`interval` (`day` ou `week`) + `interval_count`
Webhooks	Payload da v1	Envelope com `webhook_version: "v2"` e o objeto da API em `data`

Equivalência de rotas

API v1	API v2
`POST /v1/charge`	`POST /v2/orders`
`GET /v1/charge/{code}`	`GET /v2/orders/{id}` e `GET /v2/charges/{id}`
`POST /v1/charge/refund/{code}`	`POST /v2/charges/{id}/refund`
`POST /v1/orders/{order_code}/confirmations/{confirmation_id}/verify`	`POST /v2/orders/{id}/confirm`
`POST /v1/orders/{order_code}/confirmations/{confirmation_id}/resend`	`POST /v2/orders/{id}/confirm/resend`
`POST /v1/clients/{clientCode}/cards/tokens`	`POST /v2/cards`
`GET /v1/clients/{clientCode}/cards/{cardId}`	`GET /v2/cards/{id}`
`POST /v1/subscriptions`	`POST /v2/subscriptions`
`PUT /v1/subscriptions/cancel/{subscription_code}`	`POST /v2/subscriptions/{id}/cancel`
`PUT /v1/subscriptions/change-card/{subscription_code}` e `PUT /v1/subscriptions/change-payment-method/{subscription_code}`	`POST /v2/subscriptions/{id}/payment-method`
`PUT /v1/subscriptions/{subscription_code}/items/{item_code}`	`POST /v2/subscriptions/{id}/items/{code}`
`GET /v1/subscriptions/{subscription_code}/invoices`	`GET /v2/subscriptions/{id}/invoices`
`POST /v1/invoices/{invoice_code}/pay-overdue`	`POST /v2/invoices/{id}/pay`

Novidades da v2

POST /v2/orders/{id}/capture e POST /v2/orders/{id}/cancel — captura manual e cancelamento de pedidos autorizados.
POST /v2/subscriptions/{id}/next-billing-date — altera a data da próxima cobrança.
GET /v2/subscriptions/{id} e GET /v2/invoices/{id} — consulta direta de assinatura e fatura.

Continua na v1

Links de pagamento, Análise de Fraude, gestão de endpoints de webhook e a listagem, edição e exclusão de cartões não têm rota na v2. Use a API v1 para esses recursos.

Pontos de atenção

Um pedido criado pela v1 não é encontrado em GET /v2/orders/{id}. Consulte pela v2 os pedidos criados pela v2.

O formato do webhook depende de onde o recurso foi criado: pedidos e assinaturas criados pela v2 geram webhooks no formato v2; os criados pela v1 continuam no formato v1. O mesmo endpoint pode receber os dois formatos. Veja Webhooks.

A v2 não tem recurso de cliente. Envie os dados do comprador em customer a cada pedido, assinatura ou cartão.

​Principais diferenças

​Equivalência de rotas

​Novidades da v2

​Continua na v1

​Pontos de atenção

Principais diferenças

Equivalência de rotas

Novidades da v2

Continua na v1

Pontos de atenção