> ## Documentation Index
> Fetch the complete documentation index at: https://docs.malga.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Guia de teste

> Guia de teste da integração com a Malga: use cartões fictícios e regras por final do número para simular aprovação, recusa e antifraude no Sandbox.

Os números de cartões a serem utilizados no teste podem ser gerados a partir de qualquer site gerador de cartões, devendo o comportamento seguir a seguinte regra:

| Cartão          | Autorizado?       | Status             |
| --------------- | ----------------- | ------------------ |
| Final 0, 1 ou 4 | SIM               | Aprovado           |
| Final 2         | NÃO               | Não autorizado     |
| Final 3         | NÃO               | Cartão expirado    |
| Final 5         | NÃO               | Cartão bloqueado   |
| Final 6         | NÃO               | Timeout            |
| Final 7         | NÃO               | Cartão cancelado   |
| Final 8         | Aleatório SIM/NÃO | Aprovado / Timeout |

<Info>
  Transações no ambiente de sandbox envolvendo tokenização funcionam normalmente
  com base em cartões de teste. Cada cartão salvo na tokenização é tratado como
  um cartão normal, podendo ser usado no processo de simulação. A informação de
  Cód. Segurança (CVV) segue a seguinte regra de validação em sandbox, CVV final
  zero "0" o cartão é validado, para qualquer outro valor o status retorna como
  não validado.
</Info>

**Se você conseguiu inserir os dados de cartão na sua aplicação cliente, criar um token, enviar os dados para o seu servidor e criar uma cobrança, então sua integração está finalizada.**

## Captura e estorno

Caso queira testar o cenário de falha na captura ou estorno, o valor **991** deverá ser utilizado como valor para essas duas requisições.

## Antifraude

Caso queira testar cenários antifraude, o valor analisado em sandbox será o final do documento enviado no nó de antifraude (`fraudAnalysis`) na criação da transação. O status retornado para antifraude seguirá as regras dispostas na tabela abaixo:

| Documento            | Autorizado? | Status    | Declined Code                             |
| -------------------- | ----------- | --------- | ----------------------------------------- |
| Final 0              | NÃO         | Pendente  | Nulo                                      |
| Final 1              | SIM         | Aprovado  | Nulo                                      |
| Final 2              | NÃO         | Falha     | Aleatório `timeout` ou `processing_error` |
| Qualquer outro final | NÃO         | Reprovado | Nulo                                      |

## Recebedores

No ambiente de sandbox, o status inicial de um recebedor é derivado de forma determinística a partir do **último dígito do documento**. O documento considerado é o `owner.document.number` e, na sua ausência, o `business.document.number` (nessa ordem de prioridade).

| Documento            | Status inicial do recebedor |
| -------------------- | --------------------------- |
| Final 7              | `pending`                   |
| Final 8              | `inactive`                  |
| Final 9              | `failed`                    |
| Qualquer outro final | `active`                    |

A cada mudança de status (na criação e na troca manual) o webhook correspondente `seller.<status>` é enviado ao cliente.

### Alterar o status de um recebedor no sandbox

Também é possível alterar manualmente o status de um recebedor em sandbox por meio de um endpoint dedicado, recebendo o webhook correspondente à mudança.

<Info>
  Este endpoint está disponível apenas no ambiente de sandbox.
</Info>

`POST /v1/sellers/{id}/status`

Cabeçalho: `X-Client-Id`

Corpo:

```json theme={null}
{
  "status": "inactive"
}
```

Valores aceitos para `status`: `pending`, `active`, `inactive`, `failed`. Após a alteração, o recebedor tem seu status recalculado e o webhook `seller.<status>` é disparado.