PURPOSE: This article explains how to use the Dashboards in the Portal


KEY INFO

This guide will show how to use the Default Dashboard in the Atomic Portal and its various tabs (Today's Transactions, Historic Transactions, Transaction Downloads, Refunds), as well as how to filter the information.

You will also find at the end a Glossary of all the terms used in the article.





TABLE OF CONTENTS





NOTE The information presented in this page relates to the Default Atomic Dashboard. Certain custom dashboards are available - please talk to your Implementations Manager if you are an onboarding merchant, or to your Relationship Manager if you are already live with APEXX.

All of the screenshots show test data, not live production data.




1. The Default Atomic Dashboard


1.1. Today’s transactions tab


This is the first tab in the Dashboard which gives you an overview of the transactions on a given day. You can further filter the information by selecting the PSP and Merchant (if multiple merchant locations have been set up in your configuration). 


  • Acceptance Rate graphs

You will find high-level information on the day’s transactions, including the overall number, the Acceptance Rate, and the Acceptance Rate excluding Failed transactions.






The Acceptance Rate data is further drilled down into Acceptance Rate by PSP (e.g. by acquirer) and Acceptance Rate by Scheme (e.g. Visa) in other graphs, to provide you with an overview of your performance. 



  • Volume graphs

The Dashboard also give you information on the overall transaction volumes split by Scheme (as shown below), by PSP, and by transaction status for you to understand how your transaction volumes are processed. 




 NOTE 

The size of the graphs can be maximised and exported to a CSV file.




1.2. Historic Transactions Tab


This tab will present you with the same graphs as above around Acceptance Rate and Volumes, however you will be able to select a date range and report on the period that is of interest to you. Simply use the From date and To date fields to select the relevant date range as shown below.



 NOTE 

The maximum Dashboard reporting period across all tabs is 13 months. 






1.3. Refund


This tab is exclusively dedicated to the refunds that you have processed within your organisation. There are several filters available that you can use to locate your refunds. 



 NOTE 

The size of the graphs can be maximised and exported to a CSV file.




From date - To Date: these fields allow you to select the date range for your search.

Merchant reference: enter the merchant reference in that field of the original transaction.

Transaction ID: enter the APEXX transaction ID of the original transaction

PSP: allows you to filter by acquirer.

Merchant: if your set-up has several locations, you can select the relevant one here.

Customer Email and Customer Name: you can use these fields to help you locate a refund if the transaction ID or merchant reference is not known.


The Refund tab will give you access to the below information - including information on the original transaction and the refund you performed.



Refund date: date at which the refund was actioned.

Transaction date: date of the original transaction.
 
Customer full name: corresponds to what was sent to APEXX in the request.

Customer address: corresponds to what was sent to APEXX in the request.

Customer email: corresponds to what was sent to APEXX in the request. If no email address was entered, you would see a “null” value.

Customer state: this value is only mandatory for transactions originating from the US and Canada.

Card type: type of card used in the original transaction.

Card brand: corresponds to the card brand of the original transaction.

Currency: currency of the original transaction.

Refund amount: amount that you refunded (it can be a full or partial amount)

Refund status: indicates the status of the refund and whether it was successful or failed, declined etc.

Original Order Amount: this is the amount of the original transaction



 NOTE 

Whenever a refund is processed, a unique refund ID is generated by APEXX - it does not correspond to the original transaction ID. The merchant reference does not change and will passed downstream to your acquirer. 





1.4. Transaction download


The transaction download allows you to search your transactions using multiple filters that are not all present on the other tabs. Your search can also be exported into CSV or Excel. 





Acquirer:  the acquirer which processed the transactions.

Reason Code: APEXX reason code on a given transaction.

Status: status of the transaction (Captured, Declined etc.).

Payment Type: what type of payment was used for the transaction (e.g. card, BNPL, Direct Debit etc.).

Issuer Country: issuer country of the card used for the transaction.

Wallet Type: allows you to select the type of Wallet used (e.g. ApplePay, GooglePay).

Masked Card Details: you can enter the masked card details of the card used (e.g. 445653XXXXXX1005).

APEXX Reconciliation ID: this is the downstream acquirer reference for that transaction.






Authorisation amount: it is the amount that has been authorised.

Captured amount: amount that has been captured (actual moving of funds from the customer).

Reason code: APEXX reason code for the transaction.

Reason message: the reason message will be shown here (for example Do Not Honour for a declined transaction). CVV result: is the outcome of the CVV being checked, not supported by all issuers.
CAVV: a value generated by the issuer during 3DS authentication.
XID: unique ID linking the 3DS transaction to authentication details.
AVS result: checks the billing address entered.
3DS result : authentication reason code.
ECI code: 3DS response codes.
Auth_code: authorisation code for the transaction.







Customer IP: if not known, it will show null. 

Customer email address: if it has not been entered in the request it will show “null”.

Billing Address: information entered by the customer.

Billing City: information entered by the customer.

Billing Country:  information entered by the customer.

Bin: first 6 or 8 digits of the card usedAcquirer: that processed the transaction.




2. Glossary of terms used in the Dashboard


You will find below a recap of all the terms that are used in the Dashboard. For an explanation on payment-related terms, please check the relevant article (link here).


 A 

  • Acquirer: this is the financial institution that represents the business (as opposed to the financial institution that represents the customer, which is the issuer). It allows the merchants to process transactions and take funds from customers. 

  • APEXX Reconciliation ID: this is the downstream acquirer reference for that transaction. This means that this is a reference that is generated by the acquirer and then returned to APEXX. This is meant to help you reconcile your transactions between the data that you can extract from the APEXX dashboard and what the Acquirer sends you. 

  • Authorisation amount: it is the amount that has been authorised, this means that there is a lock on the customer’s funds in their bank account (the transaction may appear as Pending) but no actual movement of funds has happened yet. Only when the capture takes place do the funds leave the customer’s account. An authorisation which is not captured will automatically expire between 5 or 7 days, though this can go up to 30 days, depending on the issuer. APEXX has no visibility on this.

  • Auth_code: this is the unique authorisation code for the transaction.

  • AVS result: the Address Verification Service is an anti-fraud tool which is used to compare the billing address entered by the customer to what the issuing bank has on file. Note - it is only available for cardholder addresses in the UK, US, or Canada. 


 B 

  • Billing Address: the address of the customer performing the transaction as entered by the customer.

  • Billing City:  the city of the customer as entered by the customer.

  • Billing Country:  the country of the customer as entered by the customer.

  • Bin: the first 6 or 8 digits of the card used in the transaction.


 C 

  • Captured amount: corresponds to the amount that has been captured - in that case, unlike the authorisation, there is moving of funds from the customer’s bank account. 

  • Card type: this is the type of card used in the transaction, for example Debit or Credit.

  • Card brand: This field encompasses both the card scheme (e.g. Visa, MasterCard etc.) and the card brand. A card scheme is the terminology used for Visa, MasterCard etc. while card brands correspond to the underlying card product (e.g. Business, Corporate etc.). To make it easier, we have gathered these two notions into one field.

  • CAVV: this refers to the Cardholder Authentication Verification Value (CAVV) which is  a cryptographic value generated by the issuer during the 3DS authentication. It is used to link the authentication response with the subsequent authorisation message for an e-commerce purchase

  • Currency: this field displays  thecurrency of the original transaction.

  • Customer Address: corresponds to the billing address entered by the customer.

  • Customer Email : the email address entered by the customer during checkout. If no email address was collected, the value that will appear in the Dashboard will be “null”.

  • Customer Name / Customer Full Name: this is the name the customer name as entered during checkout. It can be referred as Full Name or Name but refers to the same thing.

  • Customer IP: this is the Customer IP if the transaction originated from a computer device.  if not known, it will show null.

  • Customer state: this corresponds to the 2 or 3-letter ISO code and is a value is only mandatory for transactions originating from the US and Canada. For example, the customer would need to enter CA to indicate the state of California. It is not mandatory for non-US or Canada transactions.

  • CVV result: this indicates is the outcome of the CVV being checked. Please refer to our API documentation (here) to check what the CVV responses correspond to.


 E 


  • ECI code: the Electronic Commerce Indicator (ECI) is a response code used in 3DS transactions that will determine wether a transaction has been authenticated or not, supporting merchants in determining the next steps for a transactions based on the authentication response. There are slight differences between schemes - for further information click here.


 F 

  • From date - To Date // Start Date - End date: these fields allow you to select a time range for your search, up to 13 months.


 I 

  • Issuer Country : The issuer represents the customer in a transaction and it is the institution (e.g. a bank) that provides a payment card to a customer. Issuer country corresponds to the country in which the card was issued to the customer, not the country where the transaction happened. 


 M 

  • Masked Card Details: APEXX does not display the full card number, however you would be able to locate a transaction using the masked card details in the following format: 445653XXXXXX1005. These masked card details refer to the card that was used for the transaction. 

  • Merchant: in a context of APEXX, a merchant is an organisation that is onboarded onto our systems and for which we process transactions.  We can set up multiple “locations” which align to the way your organisation is structured. You would be able to select the relevant location via this field. 

  • Merchant reference: the merchant reference of the transaction. This value is generated by the merchant and is passed to APEXX, and then downstream to third parties (e.g. the acquirer). It is  the only value that is passed downstream, contrary to the transaction ID, which is an APEXX reference.


 O 

  • Original Order Amount: in the Refund tab, this will show the amount of the original transaction, to be compared to the refund amount which can be different in the case of a partial refund. 


 P 

  • Payment Type: this refers to the type of payment the customer used to make the transaction. There are several types available, this depends on what has been configured for your organisation, such as Buy Now Pay Later (BNPL), card (i.e using a debit card), Direct Debit, PPRO etc. 

  • PSP: in the context of the APEXX Dashboard, PSP includes acquirers as well as alternative payment methods such as PPRO, Klarna etc. 


 R 

  • Reason Code: this is the APEXX reason code for the transaction and it will give an indication as to what happened to the transaction. For example, a transaction that is declined with a reason message of Do Not Honour will have a reason code of 5. On the contrary, a transaction that is successful will show a response code of 0. This field is to be used conjointly with the Reason Message field.

  • Reason Message: this field displays the reason message associated with the reason code. For a declined transaction the reason message will be shown here (for example Do Not Honour for a declined transaction).

  • Refund amount: the refund amount shown is the amount that was refunded on a transaction. A refund can be full (i.e. the entire amount of the original transaction is refunded) or partial (i.e. only a part of the amount is refunded). You can process several partial refunds on a transaction up to the original amount of the capture (i.e. for a £100 transaction, you could do 2 partial refunds of £50 for example, but would not be able to refund beyond £100). 

  • Refund date: this date shows the date at which the refund was actioned.

    Refund status: this is the status of the refund in the Refund tab. The status would also be reflected in the transaction event on the transaction list (see Transactions article here).


 S 

  • Status: Each transaction is associated with a status. The status that will be shown in the Dashboard is the one from the last event that happens on a transaction. For example, if your transaction was refunded, the status will go from Captured to Refunded and this will be what appears in the Dashboard. There are a few transaction statuses such as Authorised, Captured, Refunded, Declined, Failed, and Cancelled. For further information on statuses, please consult this article here.


 T 

  • Transaction date: this refers to the date of the original transaction in the Refund tab, as opposed to the refund date which can be different (i.e. a refund can be actioned days or months after the original transaction date).

  • Transaction ID: This is an APEXX-generated transaction ID which can only be used within APEXX, that is to say that this ID is not passed downstream to third-party partners or acquirers. 


 W 

  • Wallet Type: it designates mobile wallets (e.g. adding your card to your phone and paying with it). There are 2 types of Wallet - ApplePay, GooglePay - depending on the type of device your customer is using. 


 X 

  • XID: is short for Transaction ID (note - not the same APEXX transaction ID) and is used during 3DS authentication. It serves as a reference that links the 3DS transaction to the authentication details that happened during the 3DS process. 


 3 

  • 3DS result : show the results of the 3DS authentication process and whether the transaction has been 3DS authenticated.