The task description: when you purchase a service or a product, the money is taken from your credit card (account) and transferred to the selected account of the company/organization.
Then the money, allocated programmatically, is distributed among end customers' accounts. Funds allocation should be implemented programmatically, using the API.
Also, there is a task to perform only partial refund of funds for the transaction. It means that the company will deduct N dollars from every refund.
One of the requirements: Described scenario should be carried out within one Payment Gateway.
The following article is a general review of such a scenario occurrence, using the existing Payment Gateways.
In general: an implementation of the money aggregation on an interim account mechanism with the following money distribution to the end customers accounts is not an easy task and usually it is prohibited by the most of the US-payment systems. The main reason is when a customer makes a payment, you process it and subsequently send the money to some company / client (third party) account. It creates a vacuum of responsibility, where your profit is much less than the amount of the processed transactions. Payment systems treat the scheme as a highly risky one. Payment systems often require some money reserve on the interim account that varies from several hundred thousand to several million dollars, plus a percentage from the transactions.
Leaping ahead, we can say that there are only three common solutions for the described task:
1. Refund
There are strict rules in what way the money can be transferred with a credit card or from one account to another one. The only way how to send the money back is to implement one of the Refund varieties. Refund is a reimbursement from the sales company account to the customer account, initiated by the sales company. It is important to remember that the money refund/transfer to the customer card/account, which did not initially participate in the payment for goods/services – can turn out to be a potential problem in the conflict situations;
This option is not checked yet and there is a suspicion that a devious solution on using refunds with a large number of transactions will not work, because payment systems will block them as an attempt of fraud.
2. ACH Services
Another solution is to use one of the ACH Services. There are some specialized ACH providers. Using their API you can both send and withdraw funds from the user's bank account.
Automated Clearing House (ACH) is an electronic network for financial transactions in the United States. ACH processes large volumes of credit and debit transactions in bundle. ACH includes salary direct transfers, deposits and payments to suppliers.
3. Credit Transactions
Some payment systems provide a possibility to make credit transactions.
Below, there are a few examples for every solution:
We think that one of the correct and legal ways to implement the payment mechanism with subsequent distribution of funds to the third parties is a consolidation of the credit card processing common mechanism + sending funds with ACH Service within one Payment Gateway.
Technically, in order to implement the task of sending money to the customer account from the seller account, there are the following embodiments:
1) The task implementation in Authorize.net.
Authorize.net payment system supports the type of "Unlinked Credit" transaction, which allows you to refund to the customer's card without any indication of the original amount and transaction ID. It allows establishing some specific refund amount. Therefore, the service disclaims all usual security measures, and the initiator takes all the risks associated with the transaction.
It is not so easy to be allowed to provide such operations; you must fill out an application (https://www.authorize.net/content/dam/authorize/documents/ecc.pdf ) and send it to the administration first. An Activation of Expanded Credit Capabilities (ECC) service can take up to two days.
The administration has the right to deny in approval of the application and, thereafter, in providing the required functionality, without providing you with any reasons.
To see the detailed description of the "Unlinked Credit" transaction you can follow the link >>
Also, Authorize.net payment system allows making ACH transactions. For these purposes, authorize.net provides eCheck.net Service.
It is important: to activate eCheck.Net service, Card Not Present account must be created and configured, because Card Present account will not work for this purpose.
Details:What is the difference between Card Not Present (CNP) and Card Present (CP)? Why does it matter?
Thus, in order to implement the task, described above, in the Authorize.net: authorize.net merchant account must be created and configured and the ACH option should be activated as well. Processing a request to create an account on Authorize.net usually takes from 3 to 5 days. Also, after your account is created, you must first activate the payment gateway account in order to start accepting payments.
To activate your account on Authorize.NET, the following information is required:
- SSN / Tax ID Number
- Bank Account and Credit Card info – seems to be filled after a merchant account has been created.
- Owner / Principal / Corporate Officer Name
- Owner / Principal / Corporate Officer SSN cipro side affects / Tax ID Number
- Name, Address, Title, Phone Number, Email Address of account Owner
Auxiliary information:
Electronic Check Process Diagram
2) PayPal (Payflow ACH Payment Service)
There is a payment management system in the ACH network. The system offers two formats of billing accounts: B2B and B2C. Only one of these formats can be used on one Payflow ACH account. If you need both, you should create several Payflow ACH accounts, one for each of the formats.
The disadvantage of not only this implementation, but of all the ACH gateways is that the transaction process is taking place not in a real time. In this case, PayPal mentions two banking days term, or from 2 to 4, if the transaction is done at the weekend. It means not only that the "seller" will get his money with two or four days delay, but also the fact that information about a non-existent account/card number, or any other validating information, which is not statistically validating one, but depends on the client's bank, will be obtained only after the aforesaid time.
It is understandable that the role of intermediate stage will be played by a PayPal account, where the transfer of funds to the bank account of the seller will be held.
3) zuora.com
This service provides a little more free approach to the returned funds. Thus, it is not necessary that an amount of refund is equal to the originally accepted one. In this way we can provide the funds return, holding a part of them. In addition, note that this procedure is not entirely uncontrolled. You need to pass the original transaction ID for the successful refunding. Read more >>
4) Network Merchants Gateway
NMI offers two API – one for transaction processing and another one for the safe storage of users. There is a ready php script with the most part of the API implemented into it.
Here is an archive with two scripts that implement API functions: www.saynotoflash.com/downloads/nmi.zip
An interesting feature of this service is that it puts no restrictions on the amount of the returned funds (as PayPal and Authorize.net do, except unbound returns). The return option in this service requires the seller to specify the ID of the original transaction; however, the refund amount may be less than the original one, thus the "return with retention" functionality is implemented.
In addition, there is a good tool for sending credits. This provides an opportunity to pay "dividends" to third parties. Certainly, the service is warning you all the time that the credit should be paid very carefully, because the vast majority of fraudulent transactions are connected with this type of operations.
5) www.braintreepayments.com
Probably, this option is considered to be the best one to implement the described task. This service involves very powerful API with its implementation in PHP.
A large number of well-known projects support payments processing using Braintree.
An example on how to send money directly to the customer's card: https://www.braintreepayments.com/features/payment-methods
Supports separate transactions:
PHP: www.braintreepayments.com/docs/php/transactions/create
.Net: www.braintreepayments.com/docs/dotnet/transactions/create
It is also possible to make a partial refund:
PHP: www.braintreepayments.com/docs/php/transactions/refund (Partial Refund)
.Net: www.braintreepayments.com/docs/dotnet/transactions/refund
Conclusion:
Subjectively, it can be concluded that it is difficult to implement the task functionality with PayPal and Authorize.net. High complexity is caused by the reputation of these services. Unlike PayPal and Authorize.net the other services provide more liberal approach in order to attract new customers.
One of the great options to send and receive payments under a Payment Gateway is www.braintreepayments.com. The service has rather good documentation, and apparently, all required features are provided without any additional problems and difficulties.