Business Payments
Read for API integration recommendations for business payment use case.
Last updated
Was this helpful?
Read for API integration recommendations for business payment use case.
Last updated
Was this helpful?
We consider all B2B and B2C transactions as business payments. Our business payments API include both transaction processing and delivery flow of business payments. Based on your requirements and agreement with Machnet, you may deliver the transactions yourself. Regardless, these are external transactions to external receivers (individuals or businesses) who may be residing in a country different from the sender.
This section will guide you through the API endpoints for the business payment use case. Please note that these are recommendations for standard flow and can be customized as per your needs.
The first step is to in our system. Make sure to indicate business: true when you register a user. Users can only be registered from the country which has been enabled for you as per your agreement with Machnet. Fields outlined as mandatory in the user object are required during registration.
Upon registration, the user will have to provide basic information on the business and details of the business representative so that necessary KYB checks can be conducted. In order to run KYB on the sender, you will have to:
Know what
Collect and send the required and information to Machnet
User KYB is conducted using the following basic information.
Name of company
Type of company
Date of formation of the company
Registered address
Mailing address
Phone number
Email address
Nature of business
No. of employees
EIN Number
EIN Document
The receive user's type (individual or business) and corridor of the transaction determines the required information of the receive user. These details are provided to you by the Machnet Team. You will have to collect all mandatory information and conditional information (if applicable), otherwise, the transaction may not be delivered to the receive user.
The sender can add a funding account and proceed to create a transaction as long as their KYB status is not UNVERIFIED and IN PROGRESS.
You may need to collect additional information for each transaction such as an invoice for business payment or the purpose of the transaction. The additional information required may be based on the transaction amount or transaction corridor. Your spec sheet will contain all the additional transactional information that need to be collected. These need to be submitted during transaction creation.
If the transaction amount exceeds the maximum transaction limit set for a user of a Client, the transaction will be CANCELED.
Once you have submitted the information, . Each piece of information required for KYB and tier verification is referred to as a CIP tag and each CIP tag has its own verification status. Only when all CIP tags required for KYB verification (listed above) are verified will the KYB status of the user be verified.
Additional information may be required based on the transaction amount and frequency. This information is outlined in your spec sheet and can also be obtained using . Based on the information, you can submit the additional information collected from the user using the or the . Each time new information is submitted, make sure to on the user to ensure verification of all submitted information.
All transactions must have an associated receiver. For business payments, the receiver could be an individual or a business.
We only support payout to bank accounts for business payments. Hence, along with the receive user details, the . The available banks and their details can be obtained using the . All banks which support business payments will have txn_supported_types as B2B and/or B2C. Funds will be directly deposited into the indicated receive user's account.
Once the required transaction information has been collected, the user will then have to . We support bank accounts and debit cards. These are added using a widget to ensure security.
You are now ready to . Please note that only users with SEND capabilities can create transactions within the limits set in the CIP documents. The transaction limits available to a user are based on the submitted KYB information and their verification status.
All transactions above the user's permitted limits and below the maximum transaction limit is placed on HOLD with the reason . In such cases, the user will need to provide additional information to increase their transaction limits. The verification status of those additional required fields (CIP tags) will be in REQUESTED status. Once this information is submitted, you will need to initiate KYC again for the user. If the submitted information is VERIFIED, the transaction will be forwarded for processing.
Even though a transaction has been created, a transaction will not be forwarded for payout to the receive user unless you send a . You can choose to send a delivery request once the funds have been debited from the sender (transaction status: PROCESSED) to contain risks or beforehand to ensure faster payments.
If you are delivering the transaction using your own payout network and NOT using our network, you will need to on our system as well.