I am working on an API that can be used between my server and my iOS app. I have an SQL database that contains an Accounts table which includes a column called BALANCE.
People can make a real money deposit to my website through PayPal or I will be allowing them to send money orders. The problem is, when the PayPal SDK checks to make sure it was a legitimate deposit, then it credits that users account balance. When I receive the money order, I credit their balance via my website.
Each time the balance is credited, a call to my API happens. The thing is, I can do this over and over without actually getting PayPal deposits or money order deposits.
See, the users will transfer balances between each others accounts. So I don't need any help with making sure deposits were legit, I got that already. Right now a simple API call will transfer one balance amount over to another account without proof that the call was for a legitimate reason. I don't want to be able to have people somehow tap into the API and credit their own balance somehow. It needs to be where people can't just alter it.
So what can I put in place so that people cannot just tap into my API and credit their balance without actually sending money? Since this is real money, I am putting a lot of time into security.
You could authenticate with OAuth, which is what the majority of web service API's are using these days.
This tutorial may be of interest to you.
Related
I've already been in discussion with many many different payment providers and I'm getting tired of endless meetings and discussions, which in the end end up that the support or their sales department was hiding a flaw in their system / confirmed one of the features below that is actually not possible; and you have to look for another provider, reprogram the entire integration with a new provider, etc.
So I wanted to ask here; does anyone here know ANY payment service provider which is compatible with a PHP + MariaDB backend, and with mobile apps as well (via Rest API calls) that have all of the following features:
Secure.
Register a Credit Card for a customer via a custom form submission; ideally send data to payment service provider via js, receive an according token from them, and store that token within your DB. Like this, your own server does not have to be PCI compliant.
Every time a customer X clicks a specific button on your website, after authenticating the request on your backend, use your token to trigger an according payment within your backend (with secured public key authentication, etc.)
Every single payment the customer X realizes has to be only authorized first ( = validate card + verify that clients has the funds, + freeze them on the card), and captured after the customer X received the booked service, days later.
The authorize and capture mechanisms must work for every single payment with the obtained payment.
refunds of captured transactions must be possible.
The KYC procedure of service providers who receive payouts has to be possible for individuals, not only for companies (believe it or not, some providers only provide company profile possibilities for payouts..)
The Service provider must ideally be internationally active, i.e. with low currency switch fees.
Split Payments must be possible (e.g. marketplace - style, customer pays fee for service to company, company takes off commission and forwards rest to service provider)
Not sure how the PHP + Maria DB has anything to do with your inquiry.
You are calling a RESTfull API, call it with any technology you want.
Most of Your requirements are pretty straightforward and can be answered by many providers.
The challenging part on your question is more on the international market place part. Which mostly depends on the KYC you mentioned, and highly depends on the country the merchant is in and type of goods you sell.
KYC for market place sellers, payout methods to sellers and so forth are heavily regulated and might be complex in multi country mode.
In your search I would explore this topic in depth.
I'm building a website in PHP where users place bids on items. Once bidding has ended, a payment needs to be paid from the winning bidder to the listing owner. But, as the website owner, I also want to take a small percentage - say 5%.
So the process would be the winning bidder pays £100 to the listing owner, and I take 5% as that transaction takes place.
What's the best way of doing this?
I've read about PayPal MassPay, but I'm not sure whether it's what I need or not.
I'm in the UK too, not US - if that effects anything.
You can use Stripe Connect to do this if you're in the UK. You would ask your users to connect their Stripe account to your Connect Application first. You would get some data back, especially a publishable_key and an access_token which you would store on your end.
The you would use those this way:
On the front-end along with Stripe.js or Stripe Checkout you need to use the publishable_key you got from the connected user when going through the Connect flow. You should not use your API key.
Once you get a card token you send it to your server where you will create a charge. There, you should not set your API key but you should pass the access_token of the connected user as a second parameter to the Create Charge API. You can see some example code in the documentation showing how to collect fees.
This would automatically deposit the funds in the connected user's Stripe account minus the Stripe fee and the application_fee you chose. The fee would need to be a specific amount and not a percentage but you can calculate this on your end when creating the charge.
Based on your question, the solution would be as following:
Seller adds a listing on your website.
Bidding starts.
Buyer bids and win. E.g. for $10
Buyer pays using PayPal to your website, where money goes to your account (website owner).
You cut 5% of it, ($0.50) and do a Payout to seller's PayPal account of $9.50.
Optionally/Generally, website owners hold the money till the end of the month, and pay the seller the final amount, (if he is selling more than one thing, or he is a big merchant.)
However, the flow should help you setup a website based on your preferences. Many websites like eBay, Free lancing, apply the similar flow.
As a PayPal Employee, I would recommend using PayPal PHP SDK for developing. All the instructions are provided here and here
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)
I have started working on a e-commerce website. This website will run PHP and MySQL and requires to have a credit system for the users; they will be able to pay with the credit, top it up by vouchers or regular payment, as well as withdraw.
Now I do have experience with credit cards processing APIs, so paying money in and out shouldn't be a problem; what however is a problem is how to securely store the credit information. Storing it as a single numeric field is not exactly ideal and potentially could be exposed fairly easily. What I was thinking is keep all the transactions and credit history of each user in a separate table, and every time they log in recalculate what should their credit be. Same would then apply before any transaction that they attempt to do.
I would like to hear what are your thoughts how this should be implemented.
EDIT: Just to clarify; my question is not on how to process credit cards and won't be storing credit card information. I will use a well known and secure API to process the payments (e.g. via paypal). However based on the credit card payments, I need to attribute the appropriate user points in a form of credit. These points would be a representation of funds on the website (whilst the money would be retained on the company account, until the user tried to make a payment/withdrawl) and would be used to make payments and withdraw funds. Again for the actual payment processing I would use secure API, however I am not sure how to implement the credit points properly from structural point of view in the application itself. I don't want to use a simple one field point system, as that I would consider very dangerous.
I hope that clears it up a bit.
Cheers
This might not be the answer you are looking for but here are my 2 cents.
In my personal opinion unless you have someone monitoring your dedicated servers 24/7 you should never in any format store credit card numbers in your database, it is just too risky.
A very nice solution I came across last year was BrainTree http://www.braintreepayments.com/. You can set up a very nice credit card payment system without taking on any liability yourself. Their API allows server to server and transparent redirect (form posts to their site and they redirect back to your site) transactions. At the same time their Vault service allows you to store credit cards on their end and you just use a token in the server to server API to process a payment. You can store the last 4 digits (which they provide in the transaction detail) in your DB along with the CC type and the token, with this you can display a drop down for the user to select which card they want to use and you just use the token when talking to their API.
The API is very nicely documented with full examples. I think you should look into them.
Edit:
I believe you should have a table as you have suggested to store all the history and 'totals' field in the users table, which can be used to display in various places. Each time a transaction a made calculate the total and cache it in this field for ready usage. However it is a good idea to re-calculate this in certain crucial places to make sure everything is in order. Even though this field is exposed but you have a full log which can help you re-calculate everything if needed.