The Dock platform enables you to externally authorize transactions through Odin. When the authorization needs to be external, all possible validations through messaging systems occur as usual and, after that, they’re passed for the issuer to validate them according to the remaining information. It means that the issuer can decide whether they want to authorize a transaction based on the rules out of our domains.
For instance: for hybrid (credit and debit) card issuers authorizing a credit mode through our services, but having debit balance stored in a checking account out of our domain, they need to send these authorization requests so that they make a decision and respond to us.
Therefore, external authorization needs to have Odin as an intermediate party for MessagingMessaging - Messaging is a concept defining that distributed systems are able to communicate through messaging (events), where the messages are “managed” by a Message Broker (messaging module/server). because the authorization message will not be sent directly to the issuer.
The issuer must define the following information to build the integration with the authorizer of Dock.
- The type, whether it is SOCKET TCPTCP - Transmission Control Protocol is one of the communication protocols for the transport layer in the OSI model’s computer network. They support the Internet global network by checking whether the data is sent in the correct sequence, without errors via network. ISO8583 or REST;
- The URL address/External IP, such as: 192.168.0.20;
- The PortPort - In computer networks, a port is a specific application software or specific process acting as a communication endpoint for a host operating system in a computer. A port is associated with a host IP address, as well as the protocol type used for communication., such as: “5222";
- The DNSDNS - Domain Name System is a distributed, hierarchy system for managing names for computers, services or any machine that is connected to the Internet or a private network.;
- The operations to be forwarded for external authorization, such as purchases, withdrawals.
The issuer must develop the integration with Dock's authorizer following the specification below, according to the type chosen.
The communication type chosen has an impacts directly the development. The issuer that have to work with the ISO type will must develop the read of the bits, while the issuer that use JSON will have ability to read REST and the communication will be given itself using the HTTP protocol, so the process is easier.
We can explain the external authorization process according to the steps below:
1 – A person makes a transaction at a merchant;
2 – The merchant passes the payment credential information and the transaction amount to the acquirer;
3 – The acquirer combines the transaction information in a message requesting authorization and passes it to the card brand;
4 – The card brand passes the authorization request to the authorizer;
5 – The authorizer receives it and makes initial validations for the transaction. They identify it must be forwarded to an external authorizer and then send the information to the issuer;
6 - The issuer reviews the request by approving or denying the transaction and responds to the authorizer;
7 – The authorizer sends the card brand a message as an authorization response, thus approving or denying the transaction;
8 – The card brand forwards the authorization response to the acquirer;
9 – The acquirer passes the result of the authorization request to the merchant;
10 – The merchant passes the result of the authorization request to the person;
11 – The person receives follow-up on their transaction authorization.
In order to see the authorizer’s response codes, click here.
The Dock platform already makes all conversions that are related to international transactions before sending them to the issuer’s external authorization.
Updated 3 months ago