We have an issue with customers getting double charged.
Today we noticed that another batch of orders was charged twice in Authorize. We don't see any sign of a second charge in the notes on Magento but the customer did receive a shipment notification from Magento on the day she was charged again. This particular order came into the system on 11/14 and was processed and shipped on 11/18. This customer emailed us today that she was charged again on 12/14/22. No one on our team has opened that order since 11/18.
Does anyone have an idea on this issue? On 11/14 we changed the settings in Authorize that allowed us to have less strict rules for having a matching billing zip and street address so we could allow the order to go through and then check ourselves if we would allow the order to be processed. None of these orders were marked as fraud though.
Given the detail you provided that the identical charge occurred again on the same day of the following month, it seems most likely you may have accidentally turned on a recurring payment option, either as an option on a virtual product of some kind or in one of your specific payment payment processing settings in the Magento Admin Panel.
Depending upon which extensions you may have installed, two other strong possibilities to check would be:
A 3rd party payment processor has given your customer the option to select a recurring charge and they accidentally activated that option.
An extension allowing customers to manage/schedule reorders through the Customer Account Management section of the Magento storefront has been accidentally activated by the customer.
Either of these two options becomes far more likely if this is occurring on some but not all orders.
Context
Me and my team are developing solutions to allow merchants with an online store to more easily deal with in store payments.
At the moment we are also considering the option to develop our own POS terminal integration (based on off-the-shelf EMV L1&L2 Certified rebranded terminals) to give a more coherent user experience to our customers.
On our online solution we support recurring payments using Stripe as our payment gateway therefore we would like to extend this option to physical stores as well.
Of course we could make it possible in the same way we do for online customers but we would like to make the payment experience as similar as possible to the one customers have when purchasing a one time payment product.
Questions
Can a POS terminal setup recurring payments?
Maybe through some trickery that allows to authorize a payment on the spot but capture it in a second moment?
End if it isn't possible and we have to rely on Stripe for this:
Is it legal to capture from an ordinary reader (without special specifications) information as Card Number, Card Holder end expiration date from a card magnetic stripe or other medium to prefill those fields?
I'm not talking about storing those information of course, just reading them to more easily add this card to Stripe.
Thank you in advance and any quality material or alternative suggestion is welcome.
A general answer is that it is possible to initiate original transaction over POS channel and issue subsequent transactions in another (like recurring ecom). The original transaction needs to perform strong cardholder authentication and its details (Transaction ID / TraceID from authorization response) have to be indicated in subsequent authorizations.
What you are describing is referring to features and services offered by one of the companies. You should refer to their support for answer if they support it and what are conditions to do it.
The use case is this; we have automated fraud detection in our system, and if we detect something that could cause money to be paid from Stripe to a bad actor, we want to pause the periodic Stripe payout from Stripe to the customer's bank account (eg: Stripe's "external account" for that customer).
There is a way to do this on the UI: https://stripe.com/docs/connect/pausing-payments-or-payouts-on-connected-accounts; dropdown on the right. I'm looking for a way to do this with an API call.
Once the fraud has been investigated and deemed OK, our operations people will use the Stripe console above to manually un-pause/continue the payouts on the normal schedule.
I'm not an expert with the Stripe API but didn't see anything in the documentation that seemed the right thing. Or even close, really.
This depends on how you are currently managing Payouts, Scheduling or Manual.
If you are using the Scheduled approach your application can trigger a change to the Connected Account when it detects something that could be fraud, setting the payout interval to manual. This will pause any payouts unless you directly trigger them via the Dashboard or API.
You could also try modifying delay_days to give yourself a little more time to run your fraud checks and shorten them to the minimum again if/when everything checks out.
Of course, if you are using just Manual payouts then you would just not trigger the payout.
I'm currently researching making online payments through Google Wallet for a website. There will not be physical goods.
I saw that there are two very different checkout API's, inapp purchases https://developers.google.com/commerce/wallet/digital/docs/ and instant buy https://developers.google.com/commerce/wallet/online/tech-overview , but I'm not really sure what exactly the differences are between the API's in terms of when you should be using one versus the other. Can anyone explain?
Instant Buy
Instant Buy allows users to use their stored payment data from Google Wallet to purchase items from a merchant, with the merchant handling the transaction through a payment processor of their choice.
Basically, when the user submits an Instant Buy request, it will appear to your app as if they just filled in a normal order with a credit card number and everything. Google doesn't take a cut of the transaction, because Google doesn't process the payment. However, whatever payment processor you use will probably take a cut.
In-App Purchases
In-app Purchases allows merchants to have Google handle the transaction and process the payment for a digital good. In this case, Google does take a cut of the transaction because they handled the payment processing.
As far as your app is concerned, you never see payment details - Google takes care of all of that. Your app just gets a notification that user X bought item Y, and then later on, Google gives you the proceeds from the transaction.
The bottom line...
If you already have a system for handling purchases and processing credit card transactions, you probably want Instant Buy. It will sit on top of your existing infrastructure (so you don't have to have duplicate code paths) and won't cost you any money beyond what you're already paying your payment processor. It also lets your users purchase any kind of goods (physical or digital), since all it's really doing is providing payment info, not payment processing.
If you don't already have a system for handling transactions, and all you want to sell are digital goods, In-App Purchases may be simpler, since it handles all of the payment processing for you, and the cut Google takes is reasonably competitive.
For your particular case:
Since it sounds like you don't already have a payment processor lined up, and you're not trying to sell physical goods, I'd suggest looking at the In-App Purchases API.
[Full disclosure: I work for Google.]
I would like to add some info regarding the transaction fees for in app purchase. Google should put this inside the documentation, not in support section. Like Apple, the fees is clearly stated in the documentation first page because this thing is important for implementing in app purchase. For Instant Buy, no transaction fees taken by Google as you need to handle the transaction yourself. (might get charge by other party)
"For applications and all in-app products that you choose to sell on Google Play, the transaction fee is equivalent to 30% of the price. You receive 70% of the payment and the remaining 30% goes to the distribution partner and operating fees."
https://support.google.com/googleplay/android-developer/answer/112622?hl=en&ref_topic=6075663
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Should be available to non-U.S. companies, easy to setup, reliable, cheap, customizable, etc. What are your experiences?
You can't really answer this kind of question with a "I like 'insert provide name here'" type answer because like so many things it is a balance and the reasons for choosing a payment processing solution tend to be complex.
Volume / Value
The most important factor in choosing a secure payment clearance service (the people who will connect to the banking networks and clear the money for you - will refer to them as SPCS) is how many widgets will you be selling at what cost. The pricing models of all the SCPS providers is based around this equation. This dictates the economics of using the service, which is nearly always the most important factor.
For example, in the UK securetrading.net have a large annual fee and high minimum transaction values (been a while since I've seen the exact numbers and they don't make it immediately obvious on the site, but this is for illustration only anyway) making it one of the most expensive solutions to use if you are selling high value low volume. Most smaller clients will fall into this model. High value is really anything over a couple of dollars. Low volume is typically anything less than tens of thousands of units per month. However, if you are running a donations service in the aftermath of an international environmental disaster (relatively low value very high volume) then they become one of the cheapest.
Factor in to this the setup costs (relatively high), and the cost to tie the service into the site (in SecureTrading's case it's very easy to do, but still a lot harder than adding a PayPal button) and you start to build up a true picture.
On the flip side, a service such as PayPal has very low setup costs (no fee to pay, and trivially easy to integrate), but relatively high transaction costs. It is great for high value / low volume transactions.
The Bank
There are two main categories of payment clearance service - Bureau and Bank Acquired.
In the UK at least NetBanx, SecureTrading and WorldPay offer both bank acquired and bureau services. ProtX and SecPay offer only bank acquired services. PayPal and its ilk operates slightly outside both definitions (see Protection below).
A Bank Acquired service plumbs into your normal banking merchant account and clears the funds straight into it. As well as charging you for this service, your bank will also take a slice, typically this is more than the SPCS provider will charge and so it actually is the bank that becomes the deciding factor.
Some banks will only work with their preferred provider. In the UK, most banks want you to have a separate Internet Merchant Account even if you already have a Merchant Account with them.
I always tell clients to shop around, as this will make a huge difference to how much their e-commerce venture can bring in. All banks are not created equal.
Bureau services effectively act as your bank at the same time as providing the clearance service. They were popular in a time when banks hadn't grasped the concept of the Internet and would prefer transactions be chiseled into stone tablets if they got their way. Often the choice between a bureau service and a bank acquired service is made for you based on circumstances.
Trading History
In many countries (including the UK), most banks won't give you a merchant account until you have been trading for a particular period of time (2 years in the UK). Your only option is then a bureau service.
Cash flow
Most bureau services will hold onto your cash as security against "charge backs".
If you sell me a Ferrari and I am horrified to learn that you've sold me a small metal toy rather than the 1.5 tonnes of Italian automotive passion I was expecting, I will complain to my credit card company who will refund me and then chase your merchant services provider for a refund. They will have to give them the refund and then chase you for the money.
It's therefore in their interests to hold on to your money for a period of 4-6 weeks to protect against this. If you sell services or goods with no capital outlay (software for instance), then you can afford this. If on the other hand, you really are having to pay your luxury car importer to provide you with stock, then cash flow becomes very important and you're going to need a bank acquired service where you can be paid immediately.
Protection
One major downside to PayPal and similar services is that it is not covered under the same regulations that govern credit cards.
Simply put, if you buy something on a credit card your card provider is liable for ensure you get what you paid for (broadly speaking, in most countries, does not constitute legal advice etc.) and if you have a problem with your purchase they will refund you very quickly and then will go and chase the person that you paid.
This is the kind of protection you hear about when Leo Laporte advertises American Express on his podcasts. It is a "Good Thing"TM. You don't have that protection with PayPal because when you use your credit card on PayPal, you are actually buying PayPal's service. So, even if you are mis-sold a product, the person you paid for the service (PayPal) didn't mis-sell, they provided the service you paid for. This breaks the chain.
PayPal don't have a legal obligation to protect you in the same way, and their record on refunding ripped off customers is less than spangly. I'm guessing they have "Caveat Emptor" writ large on the walls of their head office. :)
I'm not dissing PayPal, they are way ahead of the curve on many other security features, but just another factor to bear in mind.
End to end integration
Different services differ in their ease of integration. Oh boy do they differ. I'm sitting on some work right now to do an HSBC integration. I'd rather have a root canal. Some of the systems make big assumptions about the way you have to work with them, and are poorly designed or inflexible. Retro-fitting them to an active site can be very painful. Some of them are beautiful and easy to work with (and not necessarily less secure). The biggest difference is how you choose to integrate though.
Most services integrate by allowing you to redirect to a secure site where your customer fills in his / her details. They are finally redirected back to a page on your own site with the results of the transaction. This works well in most cases and is easiest to integrate.
When you buy something on Amazon, you don't get redirected to WorldPay, or PayPal however. If you want end-to-end integration, most services now will let the communication happen behind the scenes. Your own site has to have a decent secure server certificate of course, and the integration is necessarily more complex.
Reputation
It used to be that PayPal was used on dinky sites. You wouldn't catch Amazon using it. That perception has changed a lot, and in fact in some senses PayPal does security better than most. If your audience expects to see PayPal and you give them some other service then you may lose custom, or vice versa. These days many merchants offer a choice to customers.
UK Providers
WorldPay. Well established. Bureau and bank acquired. Relatively high transaction costs and annual costs. Fairly easy to integrate. Owned ultimately by Royal Bank of Scotland.
SecPay. Bank Acquired. Low per transaction cost and low annual cost and flexible payment models.
ProtX. Bank Acquired. Low per transaction cost and low annual cost, flexible payment models. Can be quite demanding to integrate.
HSBC. Bank Acquired. Low per transaction cost. High set up and annual costs. Very inflexible to integrate.
SecureTrading. Bureau and Bank Acquired. Low per transaction cost but high setup and annual costs. Was a doddle to integrate last time I used it (9 years ago!)
NetBanx. Bureau and Bank Acquired. Haven't used since 1996 so can't comment!
And of course PayPal, Google Checkout and Amazon FPS are well worth looking at and worth a whole answer on their own!
Summary
Told you it wasn't that simple! Usually, as developers, we're not in the position to choose for ourselves, and these decisions should be driven by the business needs of our employer / client.
Most e-commerce projects would start with PayPal or similar. When the business gets enough orders that they could save money by switching to another service, then they've got enough money to pay for the switch.
Disclaimer: I am UK based, and have performed many integrations with a whole slew of these services over the years, however the market changes all the time and things may have changed and your mileage may vary! I am not a lawyer or accountant, and if you take my advice it's not my fault :)
I'd say paypal or GoogleCheckout.
Google Checkout is either 2% + .20USD or free depending on how much you spend on adwords. If you spend a dollar on adWords, your next $10 on Google checkout is free.
Paypal is 1.9% to 2.9% + $0.30 USD (2.9% for up to $30,000/month, 1.9% for more than $100,000/month)
Without factoring in the 20/30 cents, Paypal is just barely cheaper if you sell more than $100,000 per month, and spend nothing on adwords.
http://www.authorize.net/ works well. This type of solution would allow your customer to enter his/her credit card directly.
I've been researching Google Checkout. If you require subscriptions (recurring payments) like I do - Google Checkout has it but it is still in beta. So depending on when you want to go live and your needs - you may want to use something else.
esellerate
if it is Digital stuff that you are selling, I recommend http://www.esellerate.net/ .
they have nice support for website payment, delivery of serial numbers upon sell and even have API so you can integrate the buying process into your application in case it is a desktop application.
Well by cheap do you mean processing fees or month fees? Also is this for micro or normal transactions? PayPal in my experience is an all around good choice because it offers both starter to professional level payment processing services that fit most needs.
I've looked at WorldPay and SecPay in the past; you need to know your onions to use them competently, I think - if you want really nice integration, at any rate.
Google Check-out isn't available to non-US companies. I didn't realize this until the last stages of my research, so I found it quite annoying (considering it was very easy to work with and very well documented).
Unfortunately in order to make things as convenient as possible for your end users, you're pretty much stuck with having to support Paypal. No one else comes close in terms of registered users.
I've used CyberSource in the past, and had a good experience.
They support several interfaces including SOAP, work internationally and have a pretty good web interface.
I'm not sure whether it's cheap though.
http://www.cybersource.com/products_and_services/global_payment_services/credit_card_processing/
Epoch is pretty large and available in US and EU:
http://www.epoch.com/en/index.html
I have no idea about their conditions though.
I'd have to go with paypal. I've used it in the past, and its really quite painless. All you need to do is create an account, and it's automatically available to you.
Try AlertPay, they have very competetive fees.
alertpay looks great low fees (compared with paypal), supports more countries , developers center