I need a payment gateway for my php application.I am running a software consultancy and employees are from different parts of the world. I have build an application manage invoices and pay money to them. I need this to be integrated with a payment gateway.
My organization is in USA.
I checked with some payment gateways, but they need seller account for each employee.That is not possible.
My direct requirement is the cash must be transferred from my card/bank account to my employee's bank account . I want to pay through net banking,credit/debit cards,wired transfers,etc.
Please help!!
Thank you
If your requirements are such that the employees need to invoice you first before they get paid, I don't know how you can get around the seller account requirement.
However, if all you're trying to do is simply pay your employees, and manage their invoices through a separate system, something like PayPal could work -- I think really any payment gateway could work if you could push your requirements to the point that you simply pay your employees (one process) and handle client invoices through a second process.
Last time I checked, Paypal lets you transfer to family and friends without their percentage charge, which you could possibly bend to meet your employee payment requirement, if you can offload the invoicing piece to a separate system.
First, you don't tell us enough information about your requirements: do you need support for physical goods ? if so - who's doing the fulfillment ? you can't charge a credit-card until the package was sent which makes things more complicate than most people are aware of.
Second, what you're referring to is called the re-seller model. This model is problematic since all the major credit-card companies in the US recently came up with a new requirement: a merchant that processes more than 100K a year should open his own merchant account! (that's part of PCI compliancy required from the processors).
If all you need is to pay your employees, and being able to do so globally, there's a cool company that does just that called Tiplati.
Disclosure:I work for one of the major payment processing solutions called Bluesnap
Related
Good afternoon. Interested in a question related to the integration of Stripe.
The business task is as follows: We have products in which you can invest your money (P1), we also have a system of rewards for users (P2, P3). The creator of the project (P0) also receives some kind of reward.
Question:
How to create a list of users so that they can deposit money and we can reward them with rewards in the future. I know about such objects in the Strip as Session Hescote (for debiting funds from the card) and Payout (for crediting to a bank account). But the Checkout object is created for the Customer, and Payut for the Account Connect. How to be?
Is it possible to create an Account with the Cyst type, without filling in the bank details in detail. Let's say only the card number and that's it?
Can someone share their solution? The main task is to realize investment in the project, as well as encouraging users (crediting money to the client's card).
Stripe is, in general, a ONE-WAY payment processor - FROM "Customers who make payments via various methods" TO "Business Accounts that take payments" - either the Platform, or connected Accounts. Stripe does NOT make payments or transfers to "Customers", and does NOT transfer funds between Connected Accounts.
There is a (far more complex) "Banking as a Service" as well...
Their ToS (Terms of Service) also explicitly says they generally do not support crowd-funding and equity-funding services...
Guys I found the solution, thanks for the help everyone.
I'm attaching a flow below that works for me.
Creation of a sub account in the Stripe system.
Each system user (project creator, investor, ambassador) will be created in the Stripe system as a separate user through the functionality (https://stripe.com/docs/connect).
Verification and data filling.
Each user will need to fill out their profile in Stripe for the system to work correctly. The data entry form is provided by Stripe. (https://stripe.com/docs/connect/connect-onboarding)
Investment. The money goes to the main account.
To invest in a product, you need to create a Checkout widget, this functionality is provided by Stripe. It is required to specify information about the product and set a price, and then ask the user of our system (the Investor) to enter the bank card details. (https://stripe.com/docs/payments/checkout)
The distribution of funds received between the main account and under the account.
Once funds are deposited into Stripe's account, the funds need to be distributed among customers.
To distribute funds, you need to use (https://stripe.com/docs/api/transfers)
Withdrawal of funds to the user's account.
After there is money on the client's account, you can withdraw it through the functionality (https://stripe.com/docs/api/payouts)
I'm working on a custom WHMCS payment gateway module for the Mollie payment gateway. So far I integrated one-off payments with no issue, but I'm having some trouble implementing recurring payments.
The flow for either a subscription or authorization to charge the customer on-demand differs slightly.
The flow for creating a subscription is:
Create a customer profile in Mollie
Create a mandate by performing an authorization payment - used to link a payment method to a customer (must be a payment of at least €0.01, requires user input)
Add a subscription to a mandate, telling Mollie to charge the associated card x amount every x days/weeks/months
The flow for authorizing the merchant to charge on-demand is:
Create a customer profile in Mollie
Create a mandate by performing an authorization payment - used to link a payment method to a customer (must be a payment of at least €0.01, requires user input)
Merchant sends a payment request to Mollie for every new invoice
The problem that I have is that Mollie supports multiple payment methods per customer. While WHMCS has built their gateway module system around single-method gateways such as Stripe.
What I want to do is replace the credit card management page with a custom page (preferably generated in the module, without modifying any templates) that allows customers to manage their Mollie details. This would include seeing active mandates and adding new ones (again, a mandate is basically an authorization for me to use a specific payment method for subscriptions or on-demand charging).
I could not find any way of doing this in the WHMCS documentation. Is this at all possible, or should I accept that the only way for customers to see the pages generated by my module is for them to go through an invoice first.
You are going to need to create two modules that work together, a payment gateway module and an addon module. The addon module will allow you to create client side pages where customers can enter agreements / adjust agreements and then use the _link function to display a form where clients can pick which agreement to use when paying the invoice.
Seems perhaps useful to mention for consideration that WHMCS does already support recurring payments with a mature and native UI and integrates it with good invoicing practice. The customer is sent an invoice ahead of the payment, then on the due date, the card is charged and the customer is sent a receipt. Customers can see an audit trail of these invoices in the system.
While the business and charging needs of applications vary immensely due to a variety of driving reasons, I would think that for most people implementing recurring payments using WHMCS's recurring payment is a simple and effective solution. Remember, WHMCS lives for these - as just one example, it works brilliantly well with recurring paymentsfor hosting and domain renewal; the domain is simply not renewed and reminders are sent until paid; and any hosting will expire if not paid and eventually be optionally deleted from the server. It's always going to be harder to craft these sorts of automations with subscription-based payment system - even if a webhook is triggered on successful subscription renewal. (It can be done, it's just harder and less reliable than native - what if the IPN/webhook doesn't arrive reliably, or other issues break things). I'm just advocating that any new readers consider doing this within WHMCS's very capable and time-tested recurring transaction framework for this - I think it's worth at least considering, and hasn't been mentioned above, unless I missed it. I'm also mentioning this because for those who are newer to WHMCS this may not occur as a good idea immediately. WHMCS is all about making recurring transactions easy, letting customers see an invoice trail, etc.
I realise that it is now 2022 and that this discussion was originally held in late 2016, but wanted to add this to the great ideas above for new readers.
Apologies if this is annoying; again, fully realize that legacy decisions and business factors can make it essential to stay with external recurring payments!
I am working on a site providing software as a service which is billed on a monthly basis.
The software is licensed on a per-user basis and will be extensible via optional standard modules and custom apps that can be subscribed to through an app store.
The customer can alter the number of users, subscribe or unsubscribe modules and apps every month.
Users, modules and apps should be billed along with the base software, thus the billing amount may greatly vary from month to month.
The goal is to minimize PayPal requests for approval and let customers specify an amount that is above the base subscription price so that minor purchases do not require approval by anyone with access to the company's PayPal account (unless the customer limits the amount to the original subscription price).
Which PayPal APIs would you recommend in this scenario ?
As I understood it, UpdateRecurringPaymentsProfile does not allow the amount to be increased by more than 20% within 180 days without explicit approval by the buyer, so it probably would not work if we try to first request e.g. $200, then bill only $100 and later increase back to e.g. $150, right ?
The Adaptive Payments API seems to require the seller to bill rather than have PayPal do it on a regular basis, is this correct ?
I don't know it's help full or not right now, As it is a very old post.
Instead of creating recurring profile on PayPal Server, You can store the customer's credit card on the PayPal using REST API: https://developer.paypal.com/docs/api/#vault then every month you can fetch it and charge it like recurring Payment, Also you no need to worry about how many time customer upgrade the subscription you can manage it on your server end, Or When client is no longer with the services then just remove its card from PayPal.
I suppose Authorize.net SIM method also does the same.
Hope this make sense.
I'm working on a project with a new client and they've had some problems getting a merchant account for processing their online payments due to the business type. The system works in a similar way to Just Eat/Expedia etc in that a customer places on order on the site which is then passed on to the venue, with the site taking a commission.
The client asked if we could store customer payment details in our database (encrypted) and then pass them on to the venue for processing themselves using their in-house card systems. I know there are PCI Compliance issues with this but I've not been able to get a straight answer on exactly what we need to do. I've spoken to a couple of hosting companies and one is saying we need a cluster with separate web and database servers, while another has said we won't. I've never done something like this before, I usually just farm out payment processing to somebody like SagePay etc.
This is the proposed payment flow:
Customer places order on website
Payment details are stored in database
Customer is emailed an order acknoledgement. Venue is emailed an order notification. If venue accepts the order, order and payment details are transmitted for in-house offline processing
Once the venue has taken payment in-house, the order is confirmed and payment details are deleted from the site database
Customer is emailed a final order confirmation
I want to make sure any process is right, and the last thing I want is for the site to be attacked, payment details taken, and be left liable for any losses!
Any advice would be much appreciated.
You failed to include an actual question....
However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.
Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.
It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.
It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).
It would be straightforward to change the flow you mention to include auth/settle logic:
Customer places order on website
Your site issues "auth" using credit card details, store auth code.
Customer is emailed an order acknoledgement.
Venue is emailed an order notification.
If venue accepts the order, you execute the "settle" transaction
You confirm order details to venue
Customer is emailed a final order confirmation
Weekly/monthly/whatever you issue a report to each venue showing amount outstanding and send them a cheque or whatever.
An alternative approach is to take the storage of credit card information out of your hands completely and put the burden on someone else who has the means and expertise to do so while making it easy for you to charge your customers when necessary. Authorize.Net offers their Customer Information Manager API which allows you to create payment profiles for your customers. They handle the storage of the credit card information and give you a payment ID for it. You then can charge against that payment ID whenever necessary without having to have access to the actual payment details.
I have a website where I need to reward users for their involvement by paying money into their paypal account. I have a paypal business account, and would like to know if it is possible to put money into their account automatically from just having their paypal account email address.
I am developing my website using php. Ideally, I would like to have a script on my server that when executed transfers money from my business account into their paypal account.
I am new to paypal, and having looked around I am getting confused as to all of the different APIs that are in use! MassPay keeps coming up but if possible I would rather I didnt have to pay the 2% charge on each payment - is there any other options?
The payments are not for goods or services and so could be classed as a personal transfer, would this eliminate any fees?
So my questions are:
1) Is this possible?
2) Which API is most suitable?
Thanks
Yes, it's possible but you're going to end up paying a transaction fee. I would recommend you do a batch process (that is, do one large payment request scheduled at a certain time of day) through PayPal's Mass Payment API.
You can read more about this API and how to use it here.
The way PayPal stays in business is by collecting these transaction fees. If it didn't collect them, it wouldn't be nearly as successful.
If you're looking at having more options on the transaction, including some ways to try and shift around who pays the fee, you may want to look at Adaptive Payments.
The best way is to generate a paypal button in the following URL:
https://www.paypal.com/us/cgi-bin/?cmd=_donate-intro-outside
and place it at your page... You'll still have to pay some fee (although it's a low one)