I'm after some reliable approach or algorithm that helps detect suspicious activity in online payments with credit cards. For instance, if someone makes very frequent payment requests or payment amount is beyond certain limit and so on. In theory, it's possible that payments from given user come very fast.
Any ideas?
Look into PayPal Fraud Management Filters.
Related
I need to create a subscriptions system in my app, where users can subscribe to a certain package and they must be billed monthly.
Moreover, I need to charge their credit card automatically, and without requiring them to have a PayPal account.
I read about https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/erp_overview, but is seems it's not available anymore as I click on sign up and it gives me an error ("Sorry, this feature is not available at this time.").
Then I've read about PayPal Standard Payments, which have a subscription method (https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/subscribe_buttons/)
From what I can read there is that this is what is suitable for my use case, and it says that I need to enable the above mentioned service, which it doesn't work.
Can someone point me in the right direction on what service should I use from PayPal in order to implement recurring payments (basically my users will subscribe themselves to a service on my website, and I need to charge them monthly).
Thank you.
If you're wanting to handle credit cards directly I would highly recommend going with Payments Pro w/ Recurring Payments APIs.
You'll have to pay a monthly fee to get it all activated, and it's a little bit more expensive than what you were looking at, but it will give you much greater flexibility building your application(s) into various experiences for your buyers.
I'm considering using either PayPal's adaptive payments or Stripe (depending on setup time) for a new web application! I've heard the approval process can take weeks with PayPal but I'm hoping this isn't the case. Can anyone answer the following questions for me;
Can I use adaptive Payments with a standard business account?
Does the account need to be verified and if so, how long does this take?
What if anything can I do to speed the process up?
1) Yes.
2) Yes. Verification can be instant if you have an online banking account compatible with PayPal's verification system. Otherwise you have to wait for them to deposit to small amounts into your account and then verify those amounts once you see them, which can take a few days depending on your bank.
3) Get all of your specs worked out and a demo put together on the PayPal sandbox, and then submit everything very clearly to PayPal when you do the application for you App ID. As long as everything is pretty straight forward they've been auto-approving apps pretty much instantly. If you have something unique about your application that they need to look into further it can take a few days to get done depending on the details.
Keep in mind that Stripe is credit cards only. PayPal Adaptive Payments is the whole PayPal wallet aspect of things, with credit card payments available through "guest checkout."
There are advantages and disadvantages to both. If I knew more about your application plans I could give you a better recommendation on which one you should go with, but I can tell you right now PayPal wins in almost every instance, in my opinion.
I have a bit of experience setting up online payment systems that accept credit card numbers and then pass them over to a gateway for a one time payment.
However, I now need to setup a system that can handle automatic recurring billing - where a user provides their credit card number and is automatically billed on a monthly basis from that point forward.
I am wondering what the best way to approach something like this is? (I notice that Paypal Payflow Pro does have a recurring billing feature, but I am a bit unclear on how it works.)
Any advice on the best method / service / gateway for implementing recurring billing? If possible, I would greatly prefer to avoid keeping a local record of credit card numbers for repeat processing.
Thanks (in advance) for your help.
There's a midpoint between building your own recurring billing and Auth.net's ARB or PayPal's recurring billing (both of which have their disadvantages). There are a number of providers that handle all the details and complexities of recurring billing, and simply report the charges to your payment gateway for processing at the interval you determine.
The most critical piece to look at is which services to credit card tokenization and support credit card data portability - this will ensure that your customer data isn't locked in with a billing provider and that you can take it with you if you choose another provider in the future. This also means that these providers store the customer credit card data for you, so you can greatly reduce your PCI compliance.
Take a look at Recurly (Disclaimer: I manage their customer and technical support) and Braintree. Both services will handle your recurring billing, credit card tokenization, and support credit card data portability.
Recurring billing is easy to handle and offload to a third party if your recurring amount is constant (e.g. the amount a user pays never changes in amount or frequency). Services like Authorize.Net's Automated Recurring Billing (ARB) and Paypal Payflow Pro recurring billing allow you to have those companies handle the actual recurring payments which means you don't have to store credit card information on your servers or even do anything once the subscription is created through their APIs.
If your subscriptions will vary in terms of cost or frequency, you'll need to use a service like Authorize.Net's Customer Information Manager (CIM) to create payment profiles for your customers. Basically you're storing credit card information on Authorize.Net's servers and whenever you want to make a subscription payment you tell Authorize.Net to charge the amount due to that payment profile. The drawback to this is you essentially have to build your own subscription system.
You usually find the recurring billing features in middleware gateways like Payflow Pro. In that case, it is invoked by a variation of the API you use for card processing. You usually set up the time span between billings and they perform the billing. You usually then reconcile the billing with the report that your processor sends you each month. In some cases, the payment gateway will post a notification to you that the billing was performed. You still have to reconcile the payments with the processor report because sometimes the notifications fail.
Canceling the recurring billing is also another API call.
If your gateway doesn't have the recurring feature, you obviously have to set up the billing yourself. This of course leads to storing card info and so forth. In this case, you usually tell the processor that it is a recurring transaction (which the gateway will do for you) so you get a discount on the transaction fees.
First, let apend the statement above "...tell the processor that it is a recurring transaction ...so you get a discount on the transaction fees". The true cost of credit card processing is a percentage fee and a per item fee based on the type of card presented ( and some other factors I won't delve into here.) The point being, on a wholesale price plan, the price would be the same regardless of whether it was recurring or not because there are no special rates for 'recurring' in interchange. But I digress.
"Any advice on the best method / service / gateway for implementing recurring billing?"
Don't take on storing credit card data no matter what. You can't afford the liability.
The right choice depends on several factors.
As to credit card portability, has anyone gone to Wells Fargo/ First Data and gotten their data out? (Braintree ISO/MSP). I guarantee it won't be pretty no matter what so I would focus on the right long term solution, rather than the exit strategy, though it will certainly weigh in.
Here's questions that need to be answered:
How many transactions per month? For very low volume, maybe a few hundred, pick paypal pro. It's easy to get into/ out of.
Are people more likely to pay with consumer cards or business credit cards? Interchange optimization is important if business cards. (CenPOS automatically optimizes the transaction for lowest interchange qualification, paypal and authorize.net do not)
What methods does my client accept payments? self pay on internet only? Phone orders? Mobile payments (special events or retail)? Choose a gateway that fits all their needs.
Do you need to charge on specific days- ie the 1st and 15th? Or any time? If on specific days, how will you prorate? Check the answer against the gateway flexibility.
What happens when a card expires?
What happens when a transaction is declined?
Who will need to see the payment data for customer service? How will they access it?
Determine your needs, then figure out which ones meet them.
For the record, CenPOS is the most robust solution, but may require more steps to integrate since they are newer to ecommerce.
Disclaimer: I've been a business user of paypal and authorize.net for probably a decade and more recently CenPOS. I'm also an authorize.net reseller, and CenPOS direct agent.
Just a heads-up about Payflow Gateway's Recurring Billing:
Their Instant Payment Notifications (IPN) is a fantastic feature, but only applies to their legacy APIs. For the time being, THE ONLY WAY to be notified by PayPal of a successful (recurring) billing transaction, is by inquiry. You will need to maintain a schedule to inquire, and send an individual inquiry for each, scheduled recurring billing transaction, one at a time. PayPal will not notify you if, for example:
A transaction is approaching
A transaction has occurred
This transaction was successful
This transaction resulted in fault
A credit card is approaching expiration
A dispute occurred
... and so on.
In my opinion, this renders their service useless.
I want to provide a question and answer service (I know there are thousands of such sites on the internet) to my users where someone can ask a question by specifying how much money they will give the person who provides a good answer.
When a good answer is provided, is it possible to take the money from the questioners paypal account and send it to the answering persons account automatically?
Basically, what I don't want to do is take payments from the questioner and hold it in my paypal account, then pay the answering person when his/her answer is accepted.
I will be using a LAMP configuration to make the service.
Neither the PayPal API nor the PayPal service in general provides for automatic person-to-person payments that are initiated by a third party. In other words, you must either be the payer or the payee in order to participate in a transaction; you cannot do it on behalf of another user.
Have you looked into PayPal Adaptive Payments API? From what I know it supports person-to-person money transfer. For more info visit
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_APIntro
Hope this helps.
You can use the PayPal Adaptive. Using this you can transfer money from one account to another account. Download the sample source code from GutHub https://github.com/paypal/adaptivepayments-sdk-php
I'd like to think wildly here (meaning not thoroughly so forgive me if there are mistakes). I think there are a few PayPal products you can consider. They do not perfectly fit, but here they are for your reference:
Auth / Order, Reference Transaction (aka RT), and Adaptive Payment (aka AP, but it doesn't fit your situation very much).
As I understand, your scenario would be like this:
The questioner posts a question, and agrees to pay a certain amount of money, say $5.
You don't want to hold the money. (hmm this is hard)
When a responder answers the question, and the question is selected as the best, the money is paid automatically from the questioner via PayPal.
With Auth / Order, it works like this:
The questioner "auth" you to take the $5. This money is NOT charged yet, but is still in the questioner's account. The amount can be honored too, just like you book a hotel. (Note you can honor the money for at most 29 days.)
When an answer is selected as the best and the responder is to be paid, you capture the money from the questioner. This way, they money is now in your account. (I know you don't like this...)
Then you pay the responder immediately. You can transfer money, you can use Mass Pay API, you can use PayPal Payouts API.
Well I know the best case would be that the money never appears in your account, not even a millisecond. But this is what I can think of, "immediately" is the closest to "not at all". Another problem with this way is, it's done in two steps, and in each step you or someone has to pay the fee. When you as the platform gets the money, you pay the fee, and then when you send it out, it depends on which product you use. But the good thing is, the money is never charged until it has to be charged. And it doesn't have to be charged if there is not a good answer at all.
With RT, it's similar to Auth / Order, it's an agreement between the questioner and you (the platform). The agreement lasts longer (2 years I think), but you still have to pay the responder, and you can't honor the money, meaning when you capture it, you may fail. Good thing is (or maybe this is the bad thing), you can charge the questioner many times with only one agreement.
With AP, it provides "Parallel" payment, meaning the questioner pays you AND the responder with only one payment, and you can share the payment with the responder, and you can decide who receives how much. You can also decide who pays the fee. But the problem is, the questioner has to be present to make the payment, so it's not done automatically without the questioner. (Express Checkout / EC does parallel payment too with some differences, also on the fee thing. So if you want to go AP way, you may also want to consider EC because it's a lot easier to integrate.)
I would go for Auth / Order. But maybe you can get in contact with PayPal merchant technical services and ask for more details.
https://ppmts.custhelp.com/
Or, here is the website of their documents:
https://developer.paypal.com/
Hope this helps.
Many posters have said that AP is a good choice. This is correct. You will need to request an application which provides an app ID once your app is approved by the vetting team. You apply here:
https://www.paypal-apps.com/
Provide as much detail as you can so that they don't have to come back to you with questions about your business, etc. Once it is approved, you can use the app ID provided and start development in a live environment.
If you want to get the API working while they review your app, you can use sandbox. https://developer.paypal.com/docs/classic/lifecycle/ug_sandbox/ I believe that the vetting team requires that you have a sandbox account / setup so that they can test your implementation once you are done.
Don't be fooled because you have ALL API permissions in sandbox. So if you forget to request a needed method like mass pay, you will not have that feature in live, even though it worked for you in Sandbox. If you need a feature, request it WHEN YOU APPLY. Otherwise, you will need to start a new app request. This isn't a big deal, but if time is of the essence, you will have to wait (usually 24 - 48 hours or so) for the app to be approved, barring any questions / requests that PayPal has for you.
Integration guide for AP:
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
API operations and operations for Adaptive Payments:
https://developer.paypal.com/webapps/developer/docs/classic/api/#ap
Which payment gateway should I choose from among Authorize.net, PayPal & Google Checkout?
Is there anything wrong if I provide all ? I'm planning for express checkout methods in all the three services, the direct credit card accepting service.
The more choices you offer, the more choices your customers have, so no, there is nothing wrong with offering all three.
If you potentially have customers from the EU or Asia, you may want to investigate options that are popular in those regions as well.
Keep in mind, PayPal tends to freeze money in account for some reason and have huge problems even answering email with 24 hours.
Paypal is of course the most well known and respected, however the answer actually depends on the amount of revenue your company will make (monthly and yearly averages), the average price per transaction and the number of debit card vs credit card payments you are likly to take. Without these figures it's nigh on impssible to determine which one is cheapest for you.
Authorize.Net is only a payment gateway, not a payment processor. You need to have a US based merchant account to use with Authorize.Net.
Paypal and Google Checkout are third party payment processors. They essentially are the payment gateway and merchant account rolled into one package.
It's worth noting, from the research I've done, using PayPal is cheaper than credit card processing directly. They charge less of a fee (I'm assuming because they process everything themselves, and don't go through some third party to get to the credit card company).