ReturnCode: Código de retorno da Adquirência:

Para uma nova transação aprovada tem o retorno 4; Para captura aprovadas é 6. (Mas onde eu vejo isso na documentação?) Para reembolso aprovado é o quê? 0? Onde na documentação tem falando?

Porque nos detalhes da transação com o $cieloEcommerce->getSale(paymentId) não retorna os reembolsos que foram realizados? E também não informa o valor atual da transação, tirando o valor reembolsado.. isso também não mostra.

Porque no retorno do reembolso não retorna o código da aprovação ou o TID da nova transação de reembolso realizada?

Porquê na documentação informa que o código do retorna da venda para transações realizadas com sucesso é 00 ou 000 quando na verdade é 4 na outra parte da documentação ou no retorno do sandbox?

Alguém pode me ajudar a entender esses códigos de retorno complicados e sem sentido?!

Apr 13 '17 04:04 jhonnymakis

Eu tbm achei confuso aqui tem os Códigos de Retorno das Vendas http://developercielo.github.io/Webservice-3.0/#códigos-de-retorno-das-vendas

Sobre o sandbox é importante lembrar que os resultados dependem da entrada de dados olha isso - http://developercielo.github.io/Webservice-3.0/#sandbox - tem uma tabela que dependendo do cartao que vc utiliza no teste ele gera um retorno automatico (definido na documentacao) pra vc testar seu sistema;

Apr 14 '17 04:04 benrainir

Ultima coisa, existem uns forks que ja tem algumas correcoes, olha isso - https://github.com/DeveloperCielo/API-3.0-PHP/network

Apr 14 '17 04:04 benrainir

@jhonnymakis, como exatamente está seu retorno?

Apr 14 '17 11:04 netojoaobatista

@netojoaobatista meu retorno quando eu faço uma nova transação é 4. Porém na documentação https://developercielo.github.io/Webservice-3.0/?json#códigos-de-retorno-das-vendas informa que o código para vendas aprovadas é 00 ou 000 ... isso deixa muito confuso.

Eu sei que no Sandbox dependendo do cartão que eu utilizo ele irá me retornar aprovado ou reprovado, mas porque os códigos de retorno não pode ser igual ao código de retorno de produção? Eu teria que fazer uma validação para saber se eu estou trabalhando local ou em produção para saber qual código esperar em caso de sucesso ou não. Isso deixa margem para erros, e se tratando de pagamentos, pode ser muito grave.

Na documentação não fala que o código para captura aprovada é 6, só sei que é 6 pelo retorno na API e pela mensagem de sucesso. Eu não sei quais são os demais códigos que podem ser retornados caso não aprove a captura.

Quando eu faço um reembolso ele me retorna zero (0), é este mesmo o código para reembolso aprovado? E quando não aprova o reembolso, quais são os demais códigos que a API retorna? A unica diferença é que quando eu faço um reembolso total ele muda o status da transação para 10/11 que no caso a mesma fica cancelada.

Uma outra coisa que eu acho que deveria ser corrigida é que, quando eu faço um reembolso total passando um valor maior que o valor atual da transação, ele faz o cancelamento quando na verdade deveria dar um erro informando que o valor total informado é maior que o valor atual da transação. Assim não deixa margem para erro do valor, mesmo que seja em centavos. @netojoaobatista (UPDATE)

Um outro ponto é que ao consultar uma transação eu não tenho como saber qual o valor atual da mesma, depois que eu fiz alguns reembolsos (reembolso parcial), nas APIs americanas que eu utilizo, no caso a Authorize.net eles retornam junto com os dados das transações todos os reembolsos que foram realizadas e também o valor atual tirando os reembolsos.

E por último, cada transação de crédito ou reembolso deveria retornar um código da transação TID para que possamos guardar este código e ter a certeza que a transação foi realizada e também para que possamos realizar consultas no futuro. Hoje só temos isso para uma nova transação, não temos esta informação quando é feito um reembolso.

Apr 14 '17 12:04 jhonnymakis

Eu compreendi o cenário, @jhonnymakis; agora preciso ver o a requisição e a resposta.

Apr 14 '17 12:04 netojoaobatista

$appCielo = new App_Cielo();
$merchant = $appCielo->getMerchant();
$environment = $appCielo->getEnvironment();

$xcode = rand(555, 999);

// Crie uma instância de Sale informando o ID do pagamento
$sale = new Sale($xcode);

// Crie uma instância de Customer informando o nome do cliente
$customer = $sale->customer('Jhonny Makis ' . $xcode);

// Crie uma instância de Payment informando o valor do pagamento
$payment = $sale->payment(12542);

// Crie uma instância de Credit Card utilizando os dados de teste
// esses dados estão disponíveis no manual de integração
$payment->setType(Payment::PAYMENTTYPE_CREDITCARD)
	->creditCard("123", "Visa")
	->setExpirationDate("12/2018")
	->setCardNumber("0000000000000001")
	->setHolder("Jhonny Makis " . $xcode);

// Crie o pagamento na Cielo
try {
	// Configure o SDK com seu merchant e o ambiente apropriado para criar a venda
	$sale = (new CieloEcommerce($merchant, $environment))->createSale($sale);
	$tid = $sale->getPayment()->getTid();
	$paymentId = $sale->getPayment()->getPaymentId();

	// Com o ID do pagamento, podemos fazer sua captura, se ela não tiver sido capturada ainda
	$saleCapture = (new CieloEcommerce($merchant, $environment))->captureSale($paymentId, 15700, 0);

} catch (CieloRequestException $e) {
	die(App_Cielo::getErro($e->getCieloError()->getCode()));
}

$this->noLayout()->noRender();

Apr 14 '17 12:04 jhonnymakis

RETORNO NOVA TRANSAÇÃO

Apr 14 '17 12:04 jhonnymakis

RETORNO CAPTURA

Apr 14 '17 12:04 jhonnymakis

RETORNO REEMBOLSO PARCIAL

$sale = (new CieloEcommerce($merchant, $environment))->cancelSale('0faeba2b-b7fb-44cb-b9ef-693b595920c7', 1700);

Apr 14 '17 12:04 jhonnymakis

RETORNO DE UMA CONSULTA

$sale = (new CieloEcommerce($merchant, $environment))->getSale('0faeba2b-b7fb-44cb-b9ef-693b595920c7');

Apr 14 '17 12:04 jhonnymakis

@jhonnymakis, vamos lá:

Porém na documentação https://developercielo.github.io/Webservice-3.0/?json#códigos-de-retorno-das-vendas informa que o código para vendas aprovadas é 00 ou 000 ... isso deixa muito confuso.

O retorno 00 ou 000 pode variar conforme o banco emissor retornar para o autorizador. Quanto aos outros códigos retornados no returnCode, vou investigar e atualizar a documentação se for o caso.

Uma outra coisa que eu acho que deveria ser corrigida é que, quando eu faço um reembolso total passando um valor maior que o valor atual da transação, ele faz o cancelamento quando na verdade deveria dar um erro informando que o valor total informado é maior que o valor atual da transação. Assim não deixa margem para erro do valor, mesmo que seja em centavos. @netojoaobatista (UPDATE)

É uma excelente sugestão; vou encaminhá-la para o pessoal da API. :+1:

Um outro ponto é que ao consultar uma transação eu não tenho como saber qual o valor atual da mesma, depois que eu fiz alguns reembolsos (reembolso parcial), nas APIs americanas que eu utilizo, no caso a Authorize.net eles retornam junto com os dados das transações todos os reembolsos que foram realizadas e também o valor atual tirando os reembolsos.

Essa informação deve ser gerida pela sua aplicação; a API 3.0 lida com a autorização; esse comportamento de carteira pode ser conseguido com outros produtos - como o Checkout Cielo, por exemplo -, mas na 3.0 essa informação deve ser gerida pela sua aplicação.

Apr 14 '17 12:04 netojoaobatista

@jhonnymakis Realmente vc tem razão, eu estava ignorando o ambiente sandbox, justamente por estas questões.

Apr 14 '17 14:04 benrainir

O problema principal @netojoaobatista no sandbox, o STATUS DA TRANSACAO não tem nada haver com o código de retorno e a mensagem de retorno. ( De acordo com a tabela do ambiente de produção - Códigos de Retorno das Vendas)

Apr 14 '17 14:04 benrainir

Temos dois status, @benrainir: o status da API e o status de retorno do autorizador. O status da API indica o sucesso da operação - se o JSON foi bem formatado, etc - e o status de retorno do autorizador indica o status da autorização. O problema aqui é que o returnCode também é utilizado para o status do cancelamento, captura, etc, e isso está causando a confusão. Estou investigando os retornos para os cenários e vou atualizar a documentação com as respectivas tabelas.

:smile:

Apr 14 '17 14:04 netojoaobatista

Obrigado pela resposta @netojoaobatista, Me tira um dúvida então: Cenario do SandBox: Autorizado 0000.0000.0000.0001 / 0000.0000.0000.0004 4 Operação realizada com sucesso

Tradução disto é: 1 - (Autorizado) Seguindo a tabela - Status de uma transação Authorized Todos Meio de pagamento apto a ser capturado ou pago

2 - ( Código de retorno = 4 ) Seguindo a tabela - Códigos de Retorno das Vendas Transação não autorizada. Cartão bloqueado pelo banco emissor. Transação não autorizada. Cartão bloqueado pelo banco emissor. Transação não autorizada. Entre em contato com seu banco emissor.

É isso ? Então nesse caso o pagamento não foi realizado ?

Apr 14 '17 14:04 benrainir

O método getStatus() refere-se ao Status da Transação/Venda:

"0" = "Não Finalizado - Falha ao processar o pagamento";
"1" = "Autorizado - Meio de pagamento apto a ser capturado ou pago(Boleto)";
"2" = "Pagamento Confirmado - Pagamento confirmado e finalizado";
"3" = "Denied - Negado";
"10" = "Cancelado - Pagamento cancelado";
"11" = "Estornado - Pagamento Cancelado/Estornado";
"12" = "Pendente - Esperando retorno da instituição financeira";
"13" = "Abortado - Pagamento cancelado por falha no processamento";
"20 "= "Agendado - Recorrência agendada";

Obs.: Eu particularmente utilizo essa informação para verificar se o pagamento foi autorizado, capturado, cancelado e etc...

Ref.: https://developercielo.github.io/Webservice-3.0/#status---status-de-uma-transação

ATENÇÃO: A informação abaixo não é precisa, e não deve ser considerada em produção:

O método getReturnCode() não está claro na documentação, inicialmente não fez sentido para mim e não encontrei nada sobre o código que tal método retorna, porém realizando alguns testes percebi que o código retornado bate com os status da API 1.5, logo:

"0" = "Criada / Created transaction";
"1" = "Em andamento / Transaction in progress";
"2" = "Autenticada / Authenticated transaction";
"3" = "Não autenticada / Unauthenticated transaction";
"4" = "Autorizada (O pagamento ainda precisa ser capturado) / Authorized transaction";
"5" = "Não autorizada / Unauthorized transaction";
"6" = "Capturada / Transaction captured";
"8" = "Não capturada / Transaction not captured";
"9" = "Cancelada / Transaction cancelled";
"10" = "Em autenticação / Transaction in authentication";
"12" = "Em cancelamento / Transaction in cancellation";

May 19 '17 19:05 davicrystal

Alguém conseguiu fazer/entender??

Aug 11 '17 15:08 hzvieira

@netojoaobatista retomando a discussão. Seria isso mesmo que o @davicrystal sitou?

A documentação destes status realmente deixa um pouco a desejar no quesito clareza.

Jan 22 '18 18:01 Minotti

@Minotti

Na documentação diz:

doc-status-code

Eu acredito que os códigos são diferente.

Exemplo: No Webservice 1.5 status =12 (Transação em cancelamento)

Na API 3.0 status =12 (Pendente - Esperando retorno da instituição financeira)

Pela documentação os códigos não batem, acredito eu, o que você acha?

Abraços

Jan 22 '18 19:01 frekele

@frekele de fato você não está errado, o problema é que os códigos não batem muito. Leia:

"Formado por um código de Retorno e uma mensagem, esses códigos indicam o motivo de um determinado Status dentro de uma transação. Eles indicam, por exemplo, se uma transação com status negada não foi autorizada devido saldo negativo no banco emissor. "

Este trecho diz que o returnCode e returnMessage dizem o que o Status realmente é. Então, vamos pegar por exemplo uma transação capturada: Ao ser capturada o Status vem como 2 e o returnCode como 6.

Obedecendo a documentação vamos procurar o que returnCode = 6 quer dizer sobre o status e temos a seguinte mensagem: "Transação não autorizada. Não foi possível processar a transação. Cartão cancelado permanentemente pelo banco emissor.".

Então como uma transação que já foi capturada tem um returnCode dizendo que a transação não foi autorizada?

Jan 22 '18 19:01 Minotti

Ao ser capturada o Status vem como 2 e o returnCode como 6.

Os campos status, returnCode e returnMessage são específicos da criação da venda e são específicos da API 3.0. Se você está capturando posteriormente à criação da venda, então esses returnCode e returnMessage não são aplicáveis.

Jan 22 '18 19:01 netojoaobatista

@netojoaobatista

Obrigado pelo feedback.

OK, Então devemos tratar os codigos de forma distinta.

Jan 22 '18 19:01 frekele

@netojoaobatista Ahhhh, agora ficou bem mais claro. Obrigado.

Jan 22 '18 20:01 Minotti

Na transação simples, qual retorno do campos status identifica que o pagamento foi finalizado sem erros, 1 ou 2?

Jan 16 '19 13:01 msmosso

Na transação simples, qual retorno do campos status identifica que o pagamento foi finalizado sem erros, 1 ou 2?

Olá se você está falando em identificar o pedido pago o status é 2 "Pagamento confirmado e finalizado" isso se você definiu $payment->setCapture(true); .

Se você definiu $payment->setCapture(false); //já vem false como padrão e o cartão foi aceito vai retornar a transação com o status 1" Pagamento apto a ser capturado ou definido como pago", ai você precisa capturar o pagamento para ele retornar o status 2 que é finalizado e pago.

Era essa a sua dúvida?

Jan 17 '19 11:01 edson-nascimento

Na transação simples, qual retorno do campos status identifica que o pagamento foi finalizado sem erros, 1 ou 2?

Olá se você está falando em identificar o pedido pago o status é 2 "Pagamento confirmado e finalizado" isso se você definiu $payment->setCapture(true); .

Se você definiu $payment->setCapture(false); //já vem false como padrão e o cartão foi aceito vai retornar a transação com o status 1" Pagamento apto a ser capturado ou definido como pago", ai você precisa capturar o pagamento para ele retornar o status 2 que é finalizado e pago.

Era essa a sua dúvida?

Obrigado pela resposta, Edson.

O capture false torna a transação de alguma forma mais segura ou posso deixá-lo habilitado pra não haver necessidade de, após aceitação do cartão, realizar a captura?

Jan 21 '19 12:01 msmosso

O capture false torna a transação de alguma forma mais segura

Não. O capture false só faz a pré-aprovação, mas sozinho é inócuo do ponto de vista da segurança da transação. O que você pode fazer, é contratar um anti-fraude. Aí, nesse caso, o resultado do anti-fraude unido à pré-aprovação, pode diminuir a possibilidade de charge back. Mas veja que é um conjunto. Só colocar capture false é insuficiente do ponto de vista da segurança.

Jan 21 '19 12:01 netojoaobatista

Muito obrigado, @netojoaobatista!

Jan 21 '19 12:01 msmosso

Boa noite, poderia me esclarecer uma duvida de como eu recupero os dados somente enviando o cancelamento?

Estou realizando o cancelamento assim pela API.

$environment = Environment::sandbox();

$merchant = new Merchant('MERCHANT ID', 'MERCHANT KEY');

$paymentId = 'payment';
$amount = 'valor';

try {
    $sale = (new CieloEcommerce($merchant, $environment))->cancelSale($paymentId,$amount);
   //e como que eu recupero os dados do $sale igual quando realiza uma compra ex: $payment->getPaymentId
} catch (CieloRequestException $e) {
     $x = $e->getCieloError(); // minha duvida é como que eu acesso isso separado para passar em variavel
    $error = $e->getCode(); // aqui ele não me retorna o verdadeiro Code que retorna no getCieloError().
    $mensagem = $e->getMessage();  // aqui ele não me retorna a verdadeira mensagem que retorna no getCieloError().
}

Oct 12 '19 02:10 Akira-ux

$appCielo = new App_Cielo();
$cieloEcommerce = new CieloEcommerce($appCielo->getMerchant(), $appCielo->getEnvironment());

$venda = $cieloEcommerce->getSale($credito->pagamento_id);

if ($venda->getPayment()->getStatus() == App_Cielo::TRANSACAO_CAPTURADA) { 
    $cieloReembolso = $cieloEcommerce->cancelSale($credito->pagamento_id, App_Cielo_Util::trataMoeda($valorReembolso));

    if ( !in_array($cieloReembolso->getStatus(), [App_Cielo::TRANSACAO_CANCELADA, App_Cielo::TRANSACAO_CANCELADA_ESTORNADA]))
        throw new UnexpectedValueException($cieloReembolso->getReturnMessage());
}

@Akira-ux eu faço assim.

Oct 13 '19 14:10 jhonnymakis

API-3.0-PHP
API-3.0-PHP copied to clipboard

Códigos de Retorno (Complicado saber qual é qual)

RETORNO NOVA TRANSAÇÃO

RETORNO CAPTURA

RETORNO REEMBOLSO PARCIAL

RETORNO DE UMA CONSULTA

API-3.0-PHP API-3.0-PHP copied to clipboard

Códigos de Retorno (Complicado saber qual é qual)

RETORNO NOVA TRANSAÇÃO

RETORNO CAPTURA

RETORNO REEMBOLSO PARCIAL

RETORNO DE UMA CONSULTA

API-3.0-PHP
API-3.0-PHP copied to clipboard