I work for a non-profit organisation and have created and online donations page. Recently this donations page has been used to validate stolen credit card details via the process known as Carding.
The way it works is that a slacker get hold of a whole bunch of credit details but doesn't know which numbers are good or not. So they go to a donations page and attempt a small donation ($5 or less) with the stolen card number. If the donations goes through then they can use the number for bigger purchases.
Carding can cost a non-profit a lot of money as most these "donations" will end being reversed and in some cases a charge back fee will be charged by the bank.
Has anyone else had experience with this? Also, what are some ways that I could stop it?
Off-topic, but I'll bite:
Don't accept "small" donations.
Don't accept "many" donations from the same IP address in a "short" time span.
Consider buying credit card fraud insurance.
What "small," "many," and "short" means is up to you.
If you're not doing this already, consider using PayPal exclusively for accepting credit cards.
With no programming skills required, our Donate button is an easy and affordable way to start accepting donations online.
Discounted rates for 501(c)(3) status
Your donors don't even need a PayPal account
Accept all major credit cards
Source
What they say about fraud protection:
If there's one thing people know about PayPal, it's how seriously we take security. Behind the scenes, we work to help keep you and your donors safe from fraud.
Automatic Fraud Screening
Guard your business with our relentless fraud screens, address (AVS) and card verification (CVV2) checks, and 128-bit encryption—all included at no extra charge.
PCI & CISP Compliance
PayPal adheres to international PCI (Payment Card Industry) and CISP (Cardholder Information Security Program) standards for data protection. These standards are designed to help protect your business from fraud and loss of data. Because we handle the payment card information, you don't have to worry about meeting compliance standards yourself or storing your customers' sensitive financial information.
Full disclaimer: I have no affiliation with PayPal or any credit card company. I do not run, or have any first-hand experience with, an e-commerce site, nonprofit site, or any other web site which accepts electronic payments. I am not a lawyer. I'm just a programmer.
Related
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
I would like to access the list of PayPal Giving Fund charities so that a user of my site/app could eventually donate via credit card or PayPal.
I have looked into other APIs, like Just Giving, Orghunter, Charity Navigator, all in which don't have a large variety of charities.
If you've ever visited the site https://www.humblebundle.com the idea is very similar to this. To give you an idea, it'd go something like this:
I select charities for the user to donate to for a certain category (environment, animals, etc), save to db to retrieve specific charities later
User sees charities to divide their donation using sliders. They have the possibility to swap out charities if don't like selection
User enters amount and enters their credit card or paypal account
I make the connection to PayPal API to make donation
User then gets a receipt or something like a tax receipt
I guess the questions I'm asking are:
Is there access to a list of Giving Fund charities via an API
Is it possible to donate to charities from the Giving Fund list via the API
Would this API be available to an Australian PayPal account
If there is no API for Giving Fund, is it possible to retrieve a list of charities to do this via another route in PayPal
Will there be any restrictions on the Apple and Android stores if this was an app
Thank you so much for your time!
Have you checked out www.pandapay.io ?
To answer your questions:
Is there access to a list of Giving Fund charities via an API
PandaPay has a database of every 501c3 in America, check out Pandasearch: panda-search.s3-website-us-east-1.amazonaws.com
Is it possible to donate to charities from the Giving Fund list via the API
Yes, check out www.pandapay.io/docs
Would this API be available to an Australian PayPal account
PandaPay currently only works for USD, and payments to US-based charities. That being said, most international charities have a US branch to access the American charity market (largest in the world, by far)
If there is no API for Giving Fund, is it possible to retrieve a list of charities to do this via another route in PayPal
Is PayPal really a necessary factor for your use case?
Will there be any restrictions on the Apple and Android stores if this was an app
PandaPay is closely modeled on Stripe's API, and thus iOS and Android SDKs can easily be written for easy usage in mobile applications.
PandaPay API: https://www.pandapay.io/api-reference
Stripe Example: https://stripe.github.io/stripe-ios/docs/index.html
OrgHunter can authenticate more 501(c)(3)s (affirmative or revoked) including a large number of those with affirmative determination by virtue of the fact that they are subordinates of "Group Exemptions".
In addition, the OrgHunter database includes the most robust set of charity data attributes.
Access to the dataset/platform is by API or WordPrss, Drupal, Concrete 5 plug-ins. In addition, there are .NET and standard PHP implementations.
Comparing Just Giving, Orghunter, Charity Navigator, and PayPal Giving Fund is like comparing apples to oranges to bananas to kiwis.
Just Giving focuses on tools and systems for charities, corporate programs, and campaigns on an international basis, although they did just "acquire" the assets of "JustGiving.org" as a way to expand their footprint in the United States. OrgHunter is a platform supplier inclusive of data, donation processing and compliance, upon which tech philanthropists build software and web apps connecting and routing diversity of donors to diversity of charities. Charity Navigator focuses on ratings. And finally, the PayPal Giving Fund serves PayPal customers by enabling them to make donations to a charity of choice with the following two requirements/caveats. 1. A charity MUST ENROLL in the PPGG to receive donations from the PPGF, AND 2. to receive grants, the charity MUST ALSO create a PAYPAL ACCOUNT into which the PPGF will deposit donations. Unless the policy has changed within the last two months, the PPGF will ONLY deposit grants into a PAYPAL account, otherwise the donated funds are distributed elsewhere. This is in part why the PPGF is now dealing with a class action lawsuit that asserts that PPGF was engaging in deceptive practices.
A couple of comments about your idea, particularly as it is reflected on https://www.humblebundle.com.
In all circumstances, the moment someone starts doing any sort of fundraising online, they are subject to the various fundraising and solicitation regulations of the 50 states, because "online" by definition crosses state and international borders. The IRS may determine if a charity is a legit charity, but the states govern and regulate the conduct of fundraising and solicitation.
People cannot solicit for a charity or use charity brands or trademarks without explicit permission. That means that if you want to feature, promote and fundraise for a particular subset of charities, you will need to get the charities to opt-in or buy-in to your process or program. There are companies that do this, however it is a daunting, full time job.
An alternative to enrolling and managing charities is to give users/customers the opportunity to designate a charity of choice, and thereafter "route" their contribution through a 501(c)(3) "Donor Advised Fund" to the destination charity. That is what the alliance of OrgHunter and Make My Donation do. They integrate the most dependable charity database with donation processing and regulatory compliance into a cohesive platform that is easy for software and web app developers to build into their applications that are used to support all sorts of good causes.
How shall I integrate custom shopping cart app with PayPal to accept indirect credit card payments without forcing buyers to register at PayPal?
There's a custom shopping cart web application and the task has been set to replace current credit/dept card payment with PayPal. The goal is to let the customers pay with their cards via PayPal. However, there are some constrains:
customers should enter their credit cards details (number, expiry date, secure code) not in shopping cart's page, but PayPal's page,
every payment must consists of authorization (blocking total sum) and subsequent capture if the ordered items are available and can be delivered,
customers aren't forced to create / login to PayPal account if they wish to pay via card.
The trouble is I'm really confused with the number of possible options at PayPal. The choice between REST API and Classic API isn't that problematic, but choosing the proper product from the whole list (like Classic API products or REST API products) isn't that obvious for PayPal newbie. Some other similar questions point to DoDirectPayment (but I don't know if it's the best choice) or suggest Website Payments Standard (I'm not sure if they're still available).
I was also considering Express Checkout, but the demo seems to force to create PayPal account.
ExpressCheckout is designed to be used in concert with a direct credit card acceptance method (such as PayPal's DoDirectPayment, or a non-PayPal credit card acceptance method), although it can be configured to also do guest payments. This is why the demos of the normal configuration handle only PayPal account creation; that's the normal usage.
One key question you need to ask yourself is whether you want to have access to the credit card information & be the "merchant of record" yourself or not.
YES: Doing this gives you the most flexibility, but will require you to go through some merchant vetting and carries some security obligations (PCI) even if you are using some solution which tries to distance you from the actual raw card numbers (e.g. collecting them via PayPal or Braintree code and immediatly encrypting & tokenizing them). In short: if you want full access to the card, then you have legal obligations re: handling that account access which technology can reduce but not eliminate.
NO: If you are content to always treat your customer's card information at arms length through PayPal, via the legal structure of a PayPal account (whether the user actually has a PayPal account or is just doing a "guest" payment on PayPal where they give PayPal their credit card for one-time use) then you can reduce your vetting & security constraints (no PCI requirements at all).
If you want (or need) access to the customer's card [YES above] then the "classic" API solutions are either DoDirectPayment (for when you collect the card info) or Hosted Sole Solution (for when PayPal collects the card info on their page). HSS meets all 3 of your requiremens above; DDP fails requirement #1.
If you can live with access to the customer & the payment but NOT the card account itself [NO above] then you can use Website Payments Standard, or EC with Guest Checkout option; both meet all three of your requirements.
All of the above solutions are not only still supported, but have tens or hundreds of thousands of integrated merchants and are the biggest/mainstream ways in which PayPal payments are handled.
If you prefer the newer products & are in the first category above (real card access, not guest payments) then you can also use Braintree or the RESTful APIs. These newer products don't yet have as much flexibility & coverage as the older products, but hey, less complexity can be a good thing as long as they have what you need. These products are generally designed around plugins for your web pages rather than entering card information on PayPal's site, however, so they don't meet your first requirement.
You can also do PayFlow (several variants) or Adaptive Payments or or or.... but in general I would advise picking either the most well-established or the new-and-growing options as being better supported & more future-proof.
Now that PayPal has acquired Braintree, the preferred integration method is v.zero. It is designed to be very easy to accept PayPal, Credit Cards and other options. (Venmo, Bitcoin, etc.)
We use DoExpressCheckoutPayment API function to do payment authorization. The DoExpressCheckoutPayment response has ReceiptID field, which is empty if the payment was funded from a Paypal account or is filled if the payment was by credit card. Is the ReceiptID field also filled if the payment was by debit card? If so, how can we distinguish a receipt is that is for credit card from a receipt that is for debit card? Or is there some other way to distinguish debit card payments? We get a lot of fraudulent transactions with stolen credit cards. Since credit card payments are likely fraudulent and debit card payments are likely good, we would like to have a way to know whether a payment was from credit card or debit card to help us decide whether to accept the transaction or not.
Thanks
No, PayPal does not tell you how one of their accountholders is funding a payment. That information will not be available to you.
If you will permit me to editorialize for a minute, though:
That's a Good Thing, because the reality is much more complex than debit vs. credi. You don't want to try to second-guess all of these possibilities. Payments might be partially funded from multiple sources; have conditional aka backup funding; use "cards" that are neither the debit nor credit networks you are familiar with (e.g. hybrids like China Union Pay, virtual debit cards backed by who-knows-what, ...); various bank draft networks/mechanisms; PayPal lines of credit; etc. In general, PayPal is doing a LOT of sophisticated things to detect fraud and they deliver very low fraud rates for accountholder payments.
Also: if you are processing an accountholder payment (rather than a direct credit card payment), PayPal's seller protection policies replace whatever protections (usually not much!) you would receive from card networks for Card Not Present transactions. These protections do not depend upon what funding the accountholder uses and may be very useful to you. I recommend you read the policies and determine if you can align your business so that most or all of your sales can qualify for these protections.
If your usage cannot be eligible for PayPal Seller Protections, though, then while PayPal still runs their fraud detection they have a pretty limited set of facilities for you to layer on added fraud detection of your own. They will give you a limited amount of information about the accountholder, but as I noted above this does NOT normally include the account's funding source(s).
I'm not sure this is the right place to ask but anyway:
I have an e-commerce platform that I want to monetize based on a percentage of revenue made (eg. a store that uses my platform has an order for $100, so I get 1% or $1, while they get $99).
Currently I offer paypal and credit card payments (via my merchant bank) to all stores on the platform (ie. all payments made, regardless of the store, are through the same paypal and merchant account). I then pay these stores per month which is ok for the moment because there are only a few stores using the platform.
Moving forward I want to automate this process and ideally have it operate in real time.
Paypal have an "Adaptive Payments" API that allows chained or parallel payments on a single transaction processed in real time. This means I can skim my 1% and pass the rest of the money along my customer in real time.
I was wondering if there is a similar real-time service for Credit Card processing*? If not, is there a bank/merchant that allow API payment access so I can automate payments per day or week? OR should I just transfer all money from my bank to paypal and use this to pay my customers?
*I realise you can process credit card payments through Paypal without having to sign up, but this is less than ideal. I want the credit card processing to happen on my page as at the moment I'm seeing about 70% of orders using this over paypal.
I was wondering if there is a similar real-time service for Credit Card processing?
No there isn't. True merchant accounts do not allow for split payments. Only one entity can receive a payment and it must be the business the merchant account has been set up for. Receiving the payment for someone else is called factoring and is against all of the major credit card issuers' rules. If a merchant account is found to be factoring it will be closed and the merchant who owns the account will be blacklist. This will prevent them from ever having a true merchant account again. Additionally, there is no way to send money with a merchant account other then issuing a refund for prior purchases.
If not, is there a bank/merchant that allow API payment access so I can automate payments per day or week? OR should I just transfer all money from my bank to paypal and use this to pay my customers?
Other then using adaptive payments, this is definitely the easiest and most straight forward way to accomplish this.