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.
Related
When a non-owner dev pushes a branch to our Gitlab repo, it returns a "pipeline failed" message, with the detail "Pipeline failed due to the user not being verified". On the dev's account, he's getting a prompt to add a credit card to verify him to be eligible for free pipeline minutes.
But I haven't set up any pipelines - I don't have a gitlab-ci.yml file in my repo, neither does the new branch. There are no jobs or schedules under the CI/CD tab of the project on Gitlab. So why is there a marker saying the branch failed in the pipeline?
In my case, I was using my own runner for my project. In that case also, I got this error.
I fixed the error by disabling the shared runner in my project.
Under
Setting -> CICD -> Runner (Expand) -> Under the shared runner section, disable Shared runner.
They say that they will not charge anything on the account or store the details of the card, but they actually charge $1. (which is reversed instantly)
Hence you need a card with international transactions available. (if you're not in the US).
I wonder why this declaration is not made on the website. Definitely doesn't look good on part of such a large company as GitLab!
As for the answer, providing a credit/debit card with international transactions enabled and $1 to spare does the deed.
Gitlab updates about free pipeline minutes available on GitLab.com.
Solve proplem:
Provide a credit or debit card and use the 400 free minutes with shared runners.
You use your own runner and disable shared runners for their project.
Best regards.
For all those still wondering, I contacted Gitlab recently & apparently it's an open issue with them. They said it's possible to merge the branches anyway, but in the end we just added the credit card details anyway (there was a temporary charge). Not ideal, but hopefully will get sorted soon.
This maybe is a bug, please see https://gitlab.com/gitlab-org/gitlab/-/issues/331959
All answer above is good, but maybe have a little bit misunderstanding about credit card preauthorization.
When we use credit card, shop will request bank freeze some credits (usually the total price) for this transaction. At a moment (depended on shop), they ask bank for payment and get cash. After this, bank send bill to user.
Preauthorization is a action of freeze credits.
If shop doesn't ask bank for payment, bank will not give them cash and customer will not receive bill.
Preauthorization is a way that check validity of credit card. A common amount is one U.S. dollar. This is very common on Google Play and App Store when you add a new card.
Gitlab use this way to confirm whether the credit card is valid as same.
Although it depends on their internal operations, I think Gitlab does not need to cancel the transaction specifically, the only one thing need to do is that make sure they won’t ask bank pay for this preauthorization.
Adding to what Shivem Khandelwal posted, I found this youtube video that goes through the process: https://www.youtube.com/watch?v=s3G0qxwT11c
The message that gitlab gives saying that it won't charge is a bit miss leading, because what happens is:
Gitlab charges you $1
Gitlab rollback the transaction
This flow sometimes is not logged into the credit card. Maybe this is the reason behind the sentence "we won't charge"
it happens when you have multiple projects. try to solve by yourself. easy chhe ne
My problem:
Currently in my project it's required to keep a payment in an uncaptured state for more than 7 days which is the maximum for stripe.
What I came up with atm:
I see that it can be done by remembering customer's card (using stripe's api for this of course), creating an uncaptured payment, refunding it when the 7-day period comes to an end and creating it again until we choose to finally capture it.
I guess this 'hack' will be used only once per a payment as usually we have to hold the payment for about 10 days.
Questions:
Are there any pitfalls besides that a customer will see a second payment?
Any other ways to handle this?
Thanks in advance :)
So we ended up sticking to this method described in the question, but #korben's point is true, it's still hard to handle because even if a bank can release the funds fast, we still don't know when exactly does it happen as stripe can't inform us when the customer actually got his money back whether it's two minutes or two days.
It still works for us, because the payment is not that big and happens in person, so customers can choose whether they want to give a deposit in cash or use this method which seems more comfortable.
For context (because I was recently solving this problem and came across this thread), a number of websites recommend if you have a payment that wasn't captured within seven days, then cancel the order and create a new one. For example, Shopify recommends this and the authorization expiry date is displayed on the Orders page.
However, for all of the reasons #korben mentioned, it's best practise to avoid holding authorizations for over 7 days. Additional fees are also charged when collecting charges after the standard authorization period (depending on the issuing bank of a credit card).
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
I'm working on a project where we collect payments from users using credit/debit/PayPal payments.
The service is taking payments from users on behalf of a 3rd party organisation.
Once we take the payment, minus fees, we want to transfer the amount to the organisations bank account.
For now, what we can do is pay the organisation using Online Banking BACS bank transfer.
But I would like to know if there is a way to do this automatically using an API.
If we need to somehow register the 3rd parties bank account details before making transfers, this is fine.
We just want to automate the whole process, since at the moment the transfer is a manual step.
Are there any gateways or APIs I can use for this? In the UK?
As this is still un-answered I'll throw my hat into the ring.
For the benefit of non-UK users, the UK has a central clearing system called Bacs, which is run by the major banks in the country. However, companies can also makes submissions directly to that clearing system, by using Bacs Software.
There are a number of companies that sell on-premise and online services/APIs that allow you to send money directly via Bacs (and collect Direct Debits).
DISCLAIMER: I currently work for a software company (Bottomline Technologies) which sells a Bacs API - I won't mention the product name and to see alternative companies you can simply Google for 'bacs software api'
Hope this helps
You are going in the wrong direction. You should talk to payment processors (which may or may not include your bank) about the business considerations, which probably are more important than the technological considerations. Generally you can expect something somewhat reasonable that you will (after fiddling with it enough) be able to convince to work. It doesn't matter whether this involves some sort of api library, soap calls, or other communication method.
If you honestly consider having the technological considerations more important than the business considerations, then just go with Paypal and don't write your own shopping cart stuff at all. This is easier to use and will do more of the heavy lifting for you, but which will also probably charge you more.
Once you create a real shopping cart and start handling payments yourself (i.e. taking in CC information and sending it to a payment processor), you start getting into a mess of legal and technical concerns involving PCI compliance and the like, which will apply regardless of your choice of payment processor*.
*This is US-specific, but I bet the UK has something similar.
Currently, I'm in the process of hiring a web developer who will be working on a site that processes credit cards. While he won't have the credentials to log into the payment gateway's UI he will have access to the API login and transaction key since it's embedded in the application's code.
I'd like to be aware of all the "what if" scenarios pertaining to the type of damage one could do with that information. Obviously, he can process credit cards but the money goes into the site owner's bank account so I'm not sure how much damage that could cause. Can anyone think of any other possible scenarios?
UPDATE: The payment gateway being used is Authorize.net.
Do they really need access to your production sites?
Don't store the key in your code, store it in your production database, or on a file on the production server.
Some good answers here, I'll just add that you'd probably have some trouble with PCI.
PCI-DSS specifically dictates separation of duties, isolation of production environments from dev/test, protection of encryption keys from anyone who does not require it, and more.
As #Matthew Watson said, rethink this, and dont grant production access to developers.
As an aside, if he can access the API directly, how do you ensure that "the money goes into the site owner's bank account"? Not to mention access to all that credit card data...
If the developer gets access to the raw credit card numbers that can become a bigger problem as your site can be associated with fraudulent activity, assuming the developer is a bad apple. (They could redirect account numbers, CCV, expiration date to another site, though this should be spottable through network tools and a comprehensive code review.)
Does the API perform the "$1.00" charge (or "$X.XX") to verify that a credit card can be charged a certain amount (and thus returning the result to the caller, such as "yes" or "no")? If so, it could be used to automate the validation of credit card account numbers traded on the Internet and abuse of such a system could lead back to you.
With any gateway I have worked with, the payment processor ties the API key to the specific IP or IP range of the site of the merchant. With that said, unless the malicious(?) code in question is executed on the same server as the merchant - there shouldn't be any security concerns in that regard.
If this is not the case for your merchant site - contact them and ask if this is feasible.
Does the payment gateway allow for reversal of charges? If so there is the possibility of a number of scams being run.
Does the site process refunds? Will it ever in the future?
If we're talking about nefarious uses, then the site owner might be investigated if lots of unauthorized purchases are made. How would that affect you if the owner is investigated?
From your description it seems that this developer will have access to the customer cards detail in which case the customers privacy may be compromised. You might consider wording the contract appropriately to make sure that this angle is covered.
However the main point is that if you're working on a sensitive project/information it's better for you to find people you could trust. Hiring a software house to do the job may save you some sleep later on.
First and foremost, it is best that you never store this type of information in plain text. Usually people take this as second-hand knowledge for credit card numbers (Sadly, only because of legal reasons), but any sort of private data that you don't want others with database/source-code access viewing should be encrypted. You should store the account information somewhere in a well encrypted format, and you should provide a test account for your developers to use on their development workstations. This way, only people with server access are able to see even the encrypted information.
This way, you can have a database on the developer's workstation with the test account's API information stored (hopefully encrypted) in it's local database, but when the code is mirrored onto the production server it will still use the live, real gateway information stored on the production server's database without extra code/configuration.
With this said, I don't think that a programmer with API authentication details can do too much. Either way, it's not worth the risk - in my opinion.
Hope this help.
PS: If something bad does end up happening, you can always generate a new key in the web interface on authorize.net after you've taken the precautions to make sure it wont happen again.
In the specific case of Authorize.Net they would not be able to do credits towards their own credit cards since Authorize.Net only allows this to be done on transactions performed through them within the last six months. The only exception being allowed if you are granted an exception for unlinked refunds. If you have signed the proper paperwork for this and someone has your API login and transaction key then can then process credits towards their own credit cards. The only way for you to catch this would be to monitor your statements carefully.
To help mitigate this you should change your transaction key immediately upon completion of the work they perform for you. That would render the key they have useless after 24 hours.