Is it possible to accept payments from different categories of users to different bank accounts?

[ravis]

Exploring the possibility of using Authorize.Net for a client. 

1) Can payments from users1 to 100 (say) - be credited to bank-account1 and users2-200 be credited to bank-account2? 

2) If bank-account1 belongs to one entity like a store in a retail chain(store1), and bank-account2 belongs to another(store2), will both store1 and store2 need to be register independently with Authorize.Net or can the organization (which owns both stores) register once and then route user payments to either bank account? 

3) Can a payment be split and sent to two different accounts ?

Any response will be deeply appreciated! 

[Renaissance · Accepted solution]

@ravis,

The answer to question 1 is yes. You would have to dynamically load API credentials based on the user.

The answer to question 2 is almost certainly that you would have to have 2 different auth.net accounts. I’m 99% sure that this is the case.

The answer to question 3 is almost certainly a no. I think you are asking for customer A to make a payment of $100 online and then to have $50 go to Account A and $50 go to account B. I am 99% sure that you cannot do this with auth.net. One possible exception is if you make your own payment page instead of using a hosted page. There is a remote chance you could do something like that. It would likely require you notifying the customer that 2 separate $50 charges will be made to his/her card, and you may have problems with triggering a fraud flag (as the customer would appear to be making 2 purchases with the same card in a few hundred milliseconds). This would be an SAQ D scope integration and would carry a massive PCI burden. So the short answer on this is don’t go near it. It’s a headache waiting to happen and not guaranteed to work. PayPal has a payouts API that may be able to do this. You would have to use the orders API in conjunction, and the money would go to PayPal accounts and not directly to bank accounts. PayPals API is terrible and a real pain to use, by the way.

[ravis]

@Renaissance  thank you for the thorough response! The comment about the PCI burden and Paypal API is especially useful. 

 Did try stripe but they were not working with the business area of the client (Real Estate) and we could not take that forward, even though it fitted in with our needs. Do you know of any others which could work in the field of real estate?  

[Renaissance]

@ravis  could you elaborate on this use case? I would think it is a safe assumption that you do not have people purchasing real estate electronically. Are you somehow distributing commissions for real estate sales? Your client is a brokerage?

[ravis]

You are absolutely right in that no real estate purchases are being made electronically. And no, there are no commissions being distributed. The client manages  multiple properties for student housing. They own some of the properties and manage others for their owners. The student-residents of the properties  typically pay rent at the beginning of the month to the property (in which they live). The payments cannot be made into one centralized bank account since the ownership of each property could be different, so they need to be made to the bank accounts of the different properties. Similarly, payments to Vendors who provide goods and services to these properties also need to be made by the concerned property. When we try to register as a platform - it seems to trigger some alarm bells.  It's not clear why, the only response we have had is that the real estate sector is considered high risk and these fintech platforms (stripe etc) don't work with the real estate sector. As of now, the only option seems to be to have each property register themselves separately; we keep the meta-data at our end (as opposed to using the platform) and route the payments accordingly. Thank you, once again for your response and your interest.