Once you have your Services setted up, you need to create at least one Flow to start processing payments with Tuna. We highly encourage you to create several flows and A/B tests to better leverage our payment optimization solution.
In the Flows section at Console, you will define how each payment transaction will move along between your services by using our templates.
The templates required for each flow are:
- Filters: a set of criteria that defines which transactions will go through that Flow.
- Authorization Scheme: one or more payment service to whom you will submit the transactions of this Flow.
The optional templates for each flow are::
- Fraud Verification: one or more anti-fraud service that will give feedback about how suspicious each transaction of this flow is. You can define the actions to be taken based on the anti-fraud provider response.
- Challenges: an additional verification in case you want to collect more information from the shopper before making a decision about whether to capture the payment.
- Custom services: a custom integration or feature developed for your flow (on demand).
Filters will define which transactions, based on a set of criteria defined by you, you want to process in the flow. You must include at least one filter, even if you want to apply it to all transactions that passed on this flow. The transactions that do not match the conditions of this flow will be evaluated by the next flow, as described here.
You can include several filters and combine them with AND and OR operators to define the rules you want. See below an example of a filter:
If transaction matches with: Category.Name IN Smartphones, Alcohol Drinks AND Payment.Amount greater than 1.000,00.
It is common to add at least the Payment.method.type filter to define the Authorization Scheme that will process the payment, but there are several filter criteria available:
|Category.Name||String||Item category. Ex: Smartphones.|
|Operating.System||String||The Operating System of the shopper. Ex: iOS, Android.|
|Login.Type||String||How shoppers login on your site. Ex: Google Login.|
|Payment.Amount||Number (double)||Value the shopper paid in this transaction. Ex: $100,00|
|Method.Amount||Number (double)||Value the shopper paid with a specific payment method. Ex: $80,00|
|Installments||Select||Number of installments of the payment. Picklist.|
|Payment.method.type||Select||Name of the payment type. Ex: CreditCard.|
|BIN||Number||The shopper's Card Bank Identification Number. Ex: 4040.|
|Brand.Name||String||The shopper's Card Brand. Ex: Master, Visa, Amex.|
|Customer.Email||String||The shopper's Email on this transaction. Ex: email@example.com|
|Address.State||String||The shopper's Billing Address State. Ex: SC.|
|Address.City||String||The shopper's Billing Address City. Ex: Florianópolis.|
|Address.Postal_code||Number||The shopper's Billing Address Postal Code. Ex: 88035320|
|Custom.name||String||You can set up any custom value from your integration. Ex: Custom.userid|
Authorization Scheme is the template for defining your strategy for the payment service providers that will process the transaction. You must include at least one authorization scheme. It will use at least one payment service and it must be previously set up in the Service section in Console. Make sure you include as many authorization schemes as needed to cover all your business needs. You can also define your retries and volume allocation strategy between your payment services in the authorization scheme.
In case you have better service fees for Visa with a specific payment service provider, for example, you can define in the authorization scheme to route all Visa card transactions to it.
Authorization is the process that evaluates whether a transaction can be approved or not. It considers information collected from the shopper and the payment method itself. You can define in your flow when the authorization scheme will authorize the payment, also referred as Capture.
A transaction is not authorized due to several reasons. In some cases, it can be reversed. Therefore, to increase your odds of having a better authorization rate, you can include up to two retries in your authorization scheme setup.
Fraud Verification is the template for defining your strategy for the anti-fraud service providers. It is an optional setup, but it is highly recommended to include at least one anti-fraud service provider not only to reduce fraud costs, such as chargebacks, but also to protect your checkout from attacks of malicious users or bots.
In case you want to add the Fraud Verification template in your flow, you must have at least one anti-fraud previously set up in the Service section in Console. Then you can define which actions should be taken, such as whether to capture the payment, depending on the feedback from your anti-fraud service provider.
When you have more than one flow, you need to define the priority of each of them. The flow displayed on the top of your Flow section in Console has the highest priority, while the one in the bottom has the lowest. Once a transactions is submitted, it will be first evaluated by the Filters of the flow on the top. In case it does not match their criteria, it will be evaluated by the filters of the flow right below and so on. To change the priority of your flows, just drag and drop them until they reflect the order desired.
Since the Filters defined in your Flows may not cover all the profiles of a payment transaction, it is mandatory to define your Default Flow that is fixed at the bottom of your Flows. A Default Flow is a Flow whose Filters will match all transactions.
In the Flows section in Console, you will find five metrics to support you on evaluating the efficiency of each flow. These metrics are updated frequently, but you can also see historic results based on the date range filter defined by you.
The calculation rationale of each metric depends on the payment method, also defined as payment service
It informs the percentage of transactions processed by the flow, therefore the sum of the percentage of all flows will be equal to 100%. It also includes the total amount.
It informs the ratio between your net revenue and all the transactions processed by the flow, including the ones not approved. The net revenue considers the amount of the approved transactions after your service fees and fraud cost are deducted. This metric tells how much is your margin, but you can also see it as how much you get for each $1 processed in the flow.
It also includes the total net revenue.
It informs the ratio between the amount of the approved transactions and all transactions processed by the flow.
It also includes the total amount of the approved transactions.
It informs the ratio between all the service fees charged and the amount of all transactions processed by the flow, including also the fees applicable to transactions not approved. This result considers the fees set up in the Service Fees section for each service included in the flow. To ensure you will have reliable results for this metric, keep all your service fees always updated.
It also includes the total amount of all the service fees charged.
It informs the ratio between all your fraud costs, such as chargeback, and the amount of all transactions processed by the flow.
Chargeback is when a card holder reports to the card issuer that he does not recognize the charge. It can happen due to fraud, but it is possible to dispute a chargeback in case it is a legitimate transaction. Have in mind that this process can be subject to additional charges on top of the transaction amount.