A Malga realiza o papel de hub de pagamentos, porém não realiza a liquidação financeira sendo necessário conta em uma instituição financeira integrante do sistema de pagamentos. Dessa forma, recebemos os dados enviados pelo cliente no Serviço de Charges e fazemos a comunicação com os adquirentes e PSPs. Confira abaixo a lista de provedores suportados para cobranças com Cartão de Crédito.
Veja os provedores que suportam cobrança com cartão de crédito na nossa tabela de provedores e meios de pagamento suportados.
Quando criada na Malga, a cobrança do tipo CARTÃO credit:
authorized
, pre_authorized
ou failed
;objeto | evento | descrição |
---|---|---|
transaction | pending | Evento enviado quando a cobrança é criada na Malga |
transaction | pre_authorized | Evento enviado quando é pre-autorizado o pagamento, com reserva de saldo |
transaction | authorized | Evento enviado quando é autorizado o pagamento |
transaction | failed | Evento enviado quando a cobrança é negada pela instituição financeira antes de ter sido autorizada, sem estorno financeiro |
transaction | canceled | Evento enviado quando a cobrança é cancelada antes ter sido capturada, não produzindo um estorno financeiro |
transaction | voided | Evento enviado quando a cobrança é cancelada após ter sido autorizada, produzindo um estorno financeiro |
transaction | charged_back | Evento enviado quando a cobrança é contestada por fraude |
Realize uma cobrança a partir dos dados do cartão de crédito sem tokenizar usando o Serviço de Charges.
No fluxo de pagamentos por cartão é possível realizar uma autorização que reserva o saldo e fica pendente de uma captura posterior, ou você pode já autorizar o pagamento de maneira definitiva. Alguns lojistas optam por não capturar imediatamente a transação para poderem rodar um anti-fraude próprio após reservar o saldo no cartão, e dependendo do resultado da análise confirmar ou não a transação. A vantagem de estornar uma transação que ainda não tenha sido “capturada” é que o estorno é feito imediatamente na fatura do comprador, em alguns casos quando você tenta estornar uma transação já capturada pode levar até 30 dias para constar o estorno na fatura, por isso muitos lojistas optam por não capturar automaticamente e fazer isso manualmente depois.
O flag de capture
serve para indicar se a transação deve ou não ser capturada.
Na nossa API caso você envie o atributo capture: false
iremos retornar a transação autorizada (saldo reservado no cartão) com status pre_authorized
sendo necessário que você faça um request no Serviço de Captura para forçar manualmente a captura da transação e liberar para liquidação na conta do provedor. Se a transação não for capturada em 7 dias o adquirente pode desfazer automaticamente a transação.
Caso você envie o atributo capture: true
iremos retornar a transação autorizada com status authorized
, não sendo necessário mais nenhuma ação, a transação já fica liberada para liquidação no adquirente e não precisa chamar o Serviço de Captura.
Em nosso dashboard, também é possível capturar.
No fluxo de pagamento por cartão, é possível realizar um estorno no valor total ou parcial da cobrança. No caso de estorno parcial, o lojista opta por realizar um estorno com valor inferior ao valor da venda, sendo feito o reembolso do valor parcial estornado para o comprador, permanecendo a cobrança como autorizada para liquidação do valor restante para o lojista.
Para realizar um estorno parcial, basta enviar na requisição de void um amount
inferior ao valor original da transação, sendo este amount
do estorno o valor a ser estornado. Uma vez aprovado a solicitação de estorno parcial junto ao emissor do cartão, o amount
da transação é então atualizado para o valor residual da transação após o estorno (valor da cobrança - valor estornado),
O atributo originalAmount
do objeto charge
se mantém como o valor
originalmente autorizado na transação, é o valor inicial da transação quando
aprovada. Já o atributo amount
do objeto charge
é alterado a cada
solicitação de estorno parcial, mantendo o saldo residual a receber pelo
lojista.
Importante ressaltar que podem ser realizadas diversas requisições de estorno parcial para uma mesma transação, sendo que a cada requisição nosso sistema verifica se o valor a ser estornado, (o valor enviado na requisição de void
), é menor ou igual ao valor residual da transação, não sendo possível estornar um valor superior. O histórico de requisições de estorno pode ser encontrado na listagem de transactionRequests
do objeto charge
.
O status da transação permanecerá como authorized
ou pre_authorized
enquanto restar valor a ser pago ao lojista, sendo alterado para voided
somente quando o estorno zera todo o valor a receber do lojista.
Os estornos recusados são eventos relativamente raros, mas podem ocorrer em circunstâncias específicas. A causa principal desses casos está muitas vezes relacionada com a abertura de chargebacks pouco tempo antes do estorno ser solicitado. Isso pode resultar em processamentos assíncronos, especialmente em sistemas legados de emissores, nos quais as transações não são tratadas de forma síncrona.
Um dos provedores que implementa essa funcionalidade de reversão de estorno é a ADYEN.
Embora raro, um reembolso pode falhar após você ter recebido um webhook de REEMBOLSO com success: true. Um webhook de REEMBOLSO bem-sucedido significa que nossas validações foram bem-sucedidas e enviamos a solicitação de reembolso para o esquema do cartão. No entanto, o esquema do cartão ainda pode rejeitar o reembolso. Isso pode acontecer mesmo alguns dias após você enviar a solicitação de reembolso.
Na maioria das vezes, a Adyen pode corrigir o problema, para que o comprador eventualmente receba os fundos. Às vezes, no entanto, você precisa tomar medidas por conta própria. Para saber por que um reembolso pode falhar e o que, se necessário, você precisa fazer em cada caso, consulte Reembolsos falhados.
Veja mais em https://docs.adyen.com/online-payments/refund/#refund-failed
Quando a Malga recebe um evento de reversão de estorno por parte de algum provedor, criamos um novo evento requestType revert_void
dentro da transactionRequets
da charge. Esse evento é disparado via webhook através do evento transaction.revert_void
.
Consulte todos eventos de webhook disponíveis
Exemplo estorno total
# | Tipo de operação | Valor da operação | Valor atual da charge (amount) | Status |
---|---|---|---|---|
1 | Autorização/Captura | 100 | 100 | authorized |
2 | Estorno Parcial | 10 | 90 | authorized |
3 | Estorno Total | 90 | 0 | voided |
4 | Provedor solicitou reversão do estorno | 10 | 10 | authorized |
Exemplo estorno parcial
# | Tipo de operação | Valor da operação | Valor atual da charge (amount) | Status |
---|---|---|---|---|
1 | Autorização/Captura | 100 | 100 | authorized |
2 | Estorno Parcial | 10 | 90 | authorized |
3 | Estorno Parcial | 20 | 70 | authorized |
4 | Provedor solicitou reversão do estorno | 10 | 80 | authorized |
As modificações feitas em uma cobrança para fins de estorno total, estorno parcial, ou captura podem retornar com erro no provedor. A fim de garantir o correto tratamento dos casos de exceção retornado pelos provedores nestas operações, nossa API, ao receber erro na captura/estorno, retorna HTTP Status Code 201, sendo criado um novo transactionRequest com o status failed
, porém não é modificado o status original da transação. É recomendado que você verifique o status do objeto charge retornado, ou o status do primeiro objeto da lista de transactionRequests para se certificar que a operação foi realizada com sucesso.
A Malga suporta realização de cobranças em diferentes moedas, possibilitando você processar o pagamento na moeda de preferência do comprador.
Caso a moeda informada na cobrança seja diferente da moeda de origem do cartão do comprador, o mesmo pode ter que pagar taxa adicional no seu banco para compras no exterior. O comprador pode ainda ser cobrado uma taxa adicional pelo banco caso o cartão e o lojista estejam em paises diferentes, mesmo a moeda sendo a mesma.
A moeda deve ser enviada no campo currency
do objeto charge
, sendo a moeda BRL
o valor default caso não seja informado pelo solicitante. O código da moeda deve ser enviado no padrão ISO 4217, com todas as letras em maiúsculo.
Importante, a aceitação da moeda é condicionado ao provedor de pagamentos escolhido, somente alguns provedores suportam cobrança em diferentes moedas. Consulte o nosso suporte para saber se seu provedor suporta pagamentos em outras moedas.
Consulte a tabela de moedas aceitas
Consulte como criar uma transação utilizando Split clicando aqui;