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.
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.
In my current company, we are sometimes approving our own pull requests for the sake of bugfixing. If it's a small bug, or someone has breakdown service, they are required to be able to fix things quickly.
Because some people abuse this functionality to approve their own 'features', I wish to remove the ability to do this, except if the there are only 'bug' workitems linked to the PR.
As far as I have seen, I can only check some marks regarding the policy of the masterbranch.
Can I create a policy to enable people to approve their own pull requests, if no work-items other than bug items are linked to it?
That's not supported in Azure Pipelines - it's either allowed or not based on your branch policies. Everything that follows is opinion, so take it with a grain of salt - I'm not convinced that such a feature would solve your problem.
You said that you currently allow developers to approve their changes because, if there's an urgent bug they need to be able to move quickly. That's understandable. Also, developers can "game the system" by PR'ing features.
If you were to restrict branch policy to allow developers to merge PR's only if bugs are attached, what prevents the developer from putting new feature functionality into bug fixes?
In other words, your PR policies work by convention, and that convention can be broken. Your proposed solution is another convention that can be broken.
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).
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.