let's take the case of a client refusing to pay for incidentals for a car-rental example from strip's documentation.
what if the customer's bank requests the client's authentication, but the client refuses to do so... (refuses to pay)
before, we could directly bill the client even if he refuses to pay. but with 3DS I can't see a way to do that
In that instance you'd sadly probably need to get the law involved, as after September 14th there will be no way to charge a credit card in the EU without 3DS.
Related
I am working on a software that is to be used by businesses which make about $0.5mil revenue per year. I would like to incorporate into the software the option for my users to accept card payments from their clients. So far it seems I have the following options:
Manage multiple merchant accounts on behalf of my clients, however this has a few drawbacks. I would, for example, like to charge some small fee to cover the costs (about 0.1%) which I cannot accept if the payment to my user doesn't go through some stage that I can control where I can deduct the fee and send it my way. Also, about 50% of the mentioned revenue is paid for by credit or debit cards so a volume of $250,000 might not be enough to cover the fees set by the account provider.
Send everything through a merchant account that I control and then distribute the funds to the users. This, however, seems like a very small scale solution at best with the average number of payments per user per day being around 15.
The end result should be that the user enters a price in the software, this gets sent to a card reader where the user's client inserts their card and makes the payment. The amount charged includes all the fees associated. The amount paid will then be sent to some merchant account where my fee will be sent to me and the merchant fee will be deducted, the rest will be sent to my user's account. The whole point being that the user doesn't have to bother with setting up merchant account or card reader and simply gets a card reader from us which connects to the software and can immediately accept payments.
I sincerely hope I am missing something but I would appreciate any help with finding a way how to charge clients of my users and take some small fee.
So as it turns out, the best way to do this is using Stripe after all. If anyone is ever concerned, this is how I solved the problem.
Stripe is currently rolling out Managed Accounts of their Stripe Connect which can be used to effectively manage Stripe accounts for my customers. Therefore, once a user registers for my payment program, I create a managed account for them without the user knowing at all. For incoming Stripe payments I can then use the destination property as the id of the account where the money should go and specify an application fee which will be charged to my own account.
From there on the only problem to solve is that Stripe only supports online payments which can be overcome by using for example Payworks, however so far their service has been pretty terrible so this may be a weak point in the system.
The title pretty much sums my problem up. Is it possible I can use Paypal or something else instead?
From this help article, apparently not.
If you want a reasoning for this:
The developer signup fee is there to verify your identity, not to milk money off developers. This is why it's a token $5 amount.
Paypal is a semi-anonymous (as far as sellers are concerned) payment system. Google Wallet would only allow a credit/debit card that has your name, and your identity is verified by the issuing bank.
I would like to implement a guarantee payment system on a website I'm working on. By that I mean that the user would insert his credit card information but no money would be drawn from it at the moment he does so. The money could only be drawn if the client does not show up at the hotel to actually pay for it. In that case the owner should be able to get some amount back. I was looking at Braintree payments but haven't found anything in their doc mentioning a system like this. How should I go about it?
You want to do an Auth Only transaction. Auth Only transactions are very similar to Authorize & Capture transactions except the transaction is not captured. The merchant is issued a six digit authorization number indicating that the funds are available and the transaction is approved. However, the merchant will not receive those funds until they capture the transaction.
Authorizations are only valid for up to 30 days from when they are issued and for up to the amount they were authorized for. For example, if an authorization was obtained for $100, the merchant may use this authorization for any transaction up to $100 for that customer. However, they cannot go over $100 with that authorization number.
An Important thing to note is that the funds from authorizations are frozen on a customer's credit card and cannot be access by that customer. From the customer's point of view, that money is essential spent. Authorizations should not be used without a customer's consent and with care.
Authorizations are captured when a Force transaction is processed.
I’m integrating authorize.net into my web application. I’ve used the direct post method (DPM)to charge the account initially. However, for each transaction I also need to set up automated reoccurring billing. How would I go about doing this without asking for the information again, particularly when after DPM posts the initial transaction, the credit card data is no longer available?
I also would like to get the status of each reoccurring transaction so it can be confirmed and followed up on if necessary.
You can't do that with DPM as it takes the user's credit card information off of your website so you don't have access to it. If you want to make an initial payment and then use ARB to create a subscription you need to use AIM with ARB.
You need to use the ARB interface in order to do recurring transactions but there are a lot of problems with it, like lack of support (send an email and wait a couple of weeks for a non-helpful response for example) and weak documentation.
Documentation for SOAP interface for Authorize.net ARB:
http://www.authorize.net/support/ARB_SOAP_guide.pdf
And for the XMl interface:
http://www.authorize.net/support/ARB_guide.pdf
ARB programming documentation:
http://developer.authorize.net/api/arb/
I just switched off of Authorize.net to USAEPAY. Here are some reasons why:
1. When you use Authorize.net ARB, your customer comes on the site to sign up, and you send the ARB request to create the subscription and you get back a success code so you give the user the subscription. Then later that night they actually try to collect the first payment and a lot of times this fails, so you get a spreadsheet emailed to you the next day about the problem. This is terrible because now you lost the opportunity to say to the customer at sign up time that the card is declined. Goodbye sale!
2. I don't know if they added this recently but they didn't have a way to verify if a customer's credit card is still valid. Imagine 3 months into a subscription the card is over the limit, or cancelled, or expired etc. You don't know so how do you prompt the customer to put in a new card? You just stop getting paid, unless you want to manually open these spreadsheets and start emailing customers. YUCK.
USAEPAY works much better, the API is easier, its much better documented and you get email responses in 1-2 days and its less expensive. For example, you can query USAEPAY to get a list of successful payments, and verify that you shouldn't deactivate the account for non-payment:
http://wiki.usaepay.com/developer/soap-1.4/methods/getcustomerreport
Before you go too far with AuthNet I highly encourage you to save yourself a lot of pain and contact FranchisePaymentNetwork (FPN) to get set up with USAEpay.
They can even POST BACK to your website to let you know if a transaction is successful or not for recurring billing transactions and you can query it to verify that customer payments are getting collected so you know if you should expire an account or not.
I am not affiliated with USAEpay or Franchise Payment Network except as a satisfied paying customer / consumer of their services.
I am developing an e-commerce website where some customers will be making frequent online purchases. With that said, I am trying to find a solution that will allow me to securely store credit card information, using Website Payments Pro, so customers do not need to re-enter credit card information every time that they make a purchase. I am aware of credit card "tokenization" services like Braintree, but they require you to use their entire payment platform. PayPal has confirmed that there are third party shopping carts out there that work with Website Payments Pro, that would securely store credit card information (as long as I am PCI compliant), but would not point me in the direction of one.
Does anyone know of a third party service that would fit my needs for this? Thanks for your time and help!
David
You can make use of PayPal's Reference Transactions API that makes a transaction ID as reference to make future transactions without entering their credit card information.This way your customers can make payments throughout the year.
Alternatively you can also make the billing agreement ID as the reference for future transactions.This way PayPal Payments Pro will pick the required details automatically from the previous transaction.Billing agreement ID has the benefit that it is not time bound for 1 year unlike transaction ID
It is very, very difficult to securely store credit card information. In fact, it was announced just two days ago that 130 million credit card numbers were stolen from major retail and finance companies that have far more resources than you probably do to secure that data.
I fully understand the desire to easily facilitate recurring payments. However, think though and understand the risk related to storing of credit card numbers before deciding to do so.
If you decide that you need to store the card numbers, I recommend hiring a security expert with a proven track record to help design your solution and then audit it once it's in place.
I think the better solution would be using paypal Vault
The Vault API provides a secure way to store customer credit cards. By storing cards with PayPal, you can avoid storing them on your servers.
so the flow should be as follow
you store customer credit card to vault, and get a card id back from paypal.
You can use that card id to make a transaction or save that card id with customer info in your database to make future transactions
Note:
A reference transaction must have occurred within the past 730 days because the ID may not be available after two years.
in the past, I have used aspdotnetstorefront, but it is an entire storefront application, including the payment gateway.
You can do this with PayPal Express if you don't want to use Pro.
https://www.paypal.com/cgi-bin/webscr?cmd=xpt/Marketing/general/RecurringPaymentFAQs-outside#Q9
Is that what you're looking for or are you looking for the actual code that uses their API?