21–30 of 68 posts
It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
So taking your own account during early development can make sense. Leaving it in is probably a bad idea tho.
It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
Funny enough, in a fintech I worked for, developers and QAs actually used their own personal credit cards and bank accounts for testing.
Interestingly, they also needed to test ApplePay, but the laptops didn't allow for adding their personal iCloud accounts. So someone in the development team got the "admin" password and distributed among devs and QA team, and they all had unprotected laptops. They probably still do.
This belongs to the class of bugs/"features" that one could refer to as "Superman 3" issues.
(And before anybody says it, yes I know they refer to Superman 3 in Office Space)
Reminds me of a similar bug in a payment processing system the company I worked for used. Long story short, overflow in Java numerical types (counting milliseconds for durations in weeks...) caused the system to go haywire and charge customers 1000x the normal amount... It turned out very profitable for the company though. Stonewalling customers and refusing charge backs is too easy. Not picking up the phone is a goo…
In the early wild-west days of ecommerce a friend working as a tester at a well known British supermarket discovered that the backend card-validation logic on their payment form was essentially "return true" ... good thing the volumes were miniscule I guess?
It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
Like, for a lot of state free application logic, or even read-only frontend stuff, just do. A roll-back or a roll-forward is easier than heavy-weight procedure.
But if payment, customer authentication, migrations of large databases comes in... Suddenly these ops-guys with their careful rollout, validation functionality, dry-runs and ring rollouts are pretty good at keeping the day boring.
In the early wild-west days of ecommerce a friend working as a tester at a well known British supermarket discovered that the backend card-validation logic on their payment form was essentially "return true" ... good thing the volumes were miniscule I guess?
Reminds me of a similar bug in a payment processing system the company I worked for used. Long story short, overflow in Java numerical types (counting milliseconds for durations in weeks...) caused the system to go haywire and charge customers 1000x the normal amount... It turned out very profitable for the company though. Stonewalling customers and refusing charge backs is too easy. Not picking up the phone is a goo…
This is not a true story because as a merchant you cannot "refuse chargebacks". In fact too many chargebacks will result in a loss of your merchant account. You should really stop making things up.
However, merchants do have an opportunity to respond to a chargeback request. Providing plausible evidence that the request is in bad faith will often result in the bank not performing an actual chargeback.
It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
Not unheard of, unfortunately. Funny enough, in a fintech I worked for, developers and QAs actually used their own personal credit cards and bank accounts for testing. Interestingly, they also needed to test ApplePay, but the laptops didn't allow for adding their personal iCloud accounts. So someone in the development team got the "admin" password and distributed among devs and QA team, and they all had unprotected l…