9.2. Roteiro — CDC com desembolso ao parceiro¶

Especificação — em construção

Os serviços descritos nesta área ainda não estão disponíveis.

Roteiro de uma operação de CDC em que o valor é liberado na conta do parceiro originador (lojista), e não na do tomador. É o cenário típico do crédito no ponto de venda.

Cenário: cliente financia uma compra na Loja Centro. Esteira de CDC com destinatarioDesembolso = 2 (Parceiro).

O que muda em relação ao EP¶

Etapa	EP	CDC com parceiro
Conta de destino	Conta do tomador	Conta do parceiro
Etapa 7 do roteiro de EP	`PUT /dados-bancarios`	`PUT /desembolso`
Quem assina a CCB	Tomador	Tomador — o parceiro não assina
Tipo de pessoa	Normalmente só PF	Pode aceitar PJ, conforme a esteira

Todo o resto é idêntico: simulação, documentos, análise de crédito, envio, formalização e carteira.

As duas etapas são mutuamente exclusivas

Com destinatarioDesembolso = 2, chamar PUT /dados-bancarios responde 409. E numa esteira de CDC com destinatarioDesembolso = 1, chamar PUT /desembolso também responde 409.

Não presuma pelo produto. CDC não implica desembolso ao parceiro: é o parâmetro da esteira que decide. Consulte destinatarioDesembolso antes de ramificar.

Visão geral¶

3. Confirmar a configuração da esteira¶

curl "https://api.vehub.com.br/credito/esteiras/18/parametros" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE"

Confirme "destinatarioDesembolso": 2. Se vier 1 ou null, siga o roteiro de EP — a etapa de desembolso não se aplica.

Anote também tipoPessoaPermitida: esteiras de CDC frequentemente aceitam PJ.

4. Listar parceiros da esteira¶

curl "https://api.vehub.com.br/credito/esteiras/18/parceiros" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE"

{
  "registros": [
    { "id": 42, "nome": "Loja Centro LTDA", "documento": "12345678000199", "ativo": true }
  ]
}

5. Verificar a conta do parceiro — antes de tudo¶

curl "https://api.vehub.com.br/credito/parceiros/42/desembolso" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE"

{
  "id": 42,
  "nome": "Loja Centro LTDA",
  "documento": "12345678000199",
  "conta": { "idBanco": 1, "agencia": "12345", "conta": "9876543", "tipo": 2, "completa": true }
}

Faça esta verificação na seleção do parceiro

Se conta.completa for false, pare aqui. A proposta será recusada no envio, e descobrir isso no fim custa o retrabalho da ficha inteira. O cadastro bancário do parceiro é completado na plataforma, em Cadastros › Parceiros — não por esta API.

Exiba nome e conta ao operador para conferência antes de seguir.

6 e 7. Simular e criar a proposta¶

Idênticos ao roteiro de EP, apenas com idEsteira = 18:

curl -X POST "https://api.vehub.com.br/credito/esteiras/18/simulacao" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Content-Type: application/json" \
  -d '{ "tipoPessoa": 1, "tipoSimulacao": 1, "valor": 4500.00, "taxa": 2.49, "quantidadeParcelas": 12, "dataPrimeiroVencimento": "2026-10-05" }'

curl -X POST "https://api.vehub.com.br/credito/esteiras/18/propostas" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d @tomador.json

Suponha idProposta = 2050.

8. Informar o parceiro originador¶

No lugar de PUT /dados-bancarios:

curl -X PUT "https://api.vehub.com.br/credito/propostas/2050/desembolso" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Content-Type: application/json" \
  -d '{ "idParceiroOriginador": 42 }'

📥 Resposta¶

{
  "sucesso": true,
  "mensagem": "Parceiro do desembolso definido com sucesso.",
  "dados": {
    "idParceiroOriginador": 42,
    "nome": "Loja Centro LTDA",
    "documento": "12345678000199",
    "conta": { "idBanco": 1, "agencia": "12345", "conta": "9876543", "tipo": 2, "completa": true }
  }
}

A conta volta na resposta para exibição ao operador.

O parceiro pode ser trocado enquanto a proposta não foi enviada. Depois do envio, fica somente leitura.

9 a 13. Restante da jornada¶

Idêntico ao roteiro de EP, passos 8 a 13:

Passo	Endpoint
Simular a proposta	`POST /credito/propostas/2050/simulacao`
Documentos	`GET` e `POST /credito/propostas/2050/documentos`
Análise de crédito	`POST /credito/propostas/2050/analise-credito`
Enviar proposta	`POST /credito/propostas/2050/envio`
Assinantes e CCB	`GET /credito/propostas/2050/assinantes` e `/ccb`
Carteira	`GET /credito/contratos/{idContrato}/parcelas`

⚠️ Pontos de atenção específicos do CDC¶

Quem paga é o tomador, quem recebe é o parceiro¶

O desembolso vai ao parceiro, mas as parcelas são do tomador. A carteira, a cobrança e a liquidação seguem exatamente como em EP — o parceiro não aparece nelas.

O parceiro não assina¶

A CCB é assinada pelo tomador (ou pelos representantes legais, se PJ). O parceiro originador não entra na lista de assinantes e não recebe convite de assinatura.

Um "parceiro", um significado¶

Nesta API, idParceiroOriginador é o lojista que originou a venda e recebe o desembolso. Não confunda com o "parceiro correspondente" configurado na esteira — ele não é obrigatório em CDC e não é exposto aqui.

Pessoa jurídica é mais comum no CDC¶

Se tipoPessoaPermitida for 0 ou 2, prepare o seu formulário para PJ: sócios, CNAE, faturamento e — o ponto que mais causa retrabalho — ao menos um representante legal, que é quem assina. Ver 4.3.

✅ Checklist adicional ao do roteiro de EP¶

destinatarioDesembolso consultado, não inferido do produto
Conta do parceiro verificada (completa: true) na seleção, não no envio
Nome e conta do parceiro exibidos ao operador antes da confirmação
Nenhuma chamada a PUT /dados-bancarios nesta configuração
Formulário preparado para PJ, com representante legal obrigatório