Remittance payments
Let’s take an example of a generic remittance payments provider to see how the Flagright API can be seamlessly used as the compliance and anti-fincrime infrastructure.
You can find the relevant case study here. If your organization also provides a wallet along with remittance payments, checkout the digital wallet use case.
Business Entities
Any business entity is represented as Business
entity in the Flagright API. Everytime a new legal entity onboards to your system, you can create them at Flagright using the Create business API.
To make the following request, you’ll need an API Key. Please reach out if you don’t have one.
Users
Consumer users - individuals on either side of the transaction - are represented as Consumer
entity in the Flagright API. You would make an API request to the POST /consumer/users
endpoint to create a new consumer, with the payload like:
To make the following request, you’ll need an API Key. Please reach out if you don’t have one.
Transactions
For remittance payments, there are typically two out of the three types of transactions:
Money out of the country
Transferring money out of the country is overwhelmingly the primary type of transaction is when a user transfers money from home country to a payment instrument (typically a bank account) in another country.
The origin payment method is the payment instrument used to send the money. The destination payment method is the payment instrument used to receive the money (typically a bank account). In this case, the originUserId
would be the user initiating the transaction.
The destinationUserId
typically would be empty, since the user receiving the payment isn’t the customer of the remittance solution.
You would make an API call to the POST /transactions
to verify this transaction before processing, with the payload like so:
To make the following request, you’ll need an API Key. Please reach out if you don’t have one.
You would make an API call to the POST /transactions
to verify this transaction before processing, with the payload like:
Money into the country
The other use case in money into the home country, where the remittance solution would allow a user to receive international payments. In this case, the originUserId
typically would be empty, since the user sending the payment isn’t the customer of the remittance payment provider and the remittance provider typically does not have information on the user. If you perform KYC on the end user and have information on them, you can pass in the consumer userId
as the originUserId
.
The destinationUserId
would be the userId
of the user receiving the payment.
You would make an API call to the POST /transactions
to verify this transaction before processing, with the payload like so:
To make the following request, you’ll need an API Key. Please reach out if you don’t have one.
You would make an API call to the POST /transactions
to verify this transaction before processing, with the payload like: