Tokens are mapped to the underlying account not to a specific card. This is one of the selling points of network tokenization to merchants. If the underlying card gets lost/stolen/replaced/etc, the token will still work because it is tied to the account and not the physical card.
The slightly tricky part is that the brand rules may still apply even if it transaction on debit rails, since the brand is printed on the card and Visa/MC doesn't want to deal with consumer complaints because the merchant routed it to debit rails despite Visa's "zero fraud guarantee" (the primary exception for this is pin debit transactions are excluded since those primarily go through debit networks). The challenge then becomes the issuer needs to take a loss as some of the debit networks don't have the chargeback infrastructure that the larger networks have, but you are often still protected by Visa rules just because the card has Visa printed on it.
Brazil has a unique thing "combo cards" in which a single card number can be tied to different accounts. So selecting credit draws from a line of credit while selecting debit draws from a bank account (checking or savings) holding cash.
In the US, though, both options draw from the same bank/checking account.
Braintree lets you move money from one place to another safely and securely. Every time you pay for an Uber ride, book a stay through Airbnb, or pay with PayPal when you check out online, you're probably using our product. We solve world-scale problems and provide opportunities to match. We build diverse teams that recognize our strengths and allow us to work on our weaknesses.
We don't have a playbook for hiring during a pandemic, and we know these are weird and stressful times for many, but we're committed to being flexible and making it work to find excellent engineering colleagues.
We use pair programming and TDD as our default practices, and we have some pretty awesome internal tooling to enable remote pairing and collaboration. We're always looking to learn and improve, and teams regularly come together to reflect and adjust. We strive to be welcoming and inclusive for all our team members.
Note that the confidence gap and imposter syndrome are real and might make you feel unqualified! Please apply anyway. We'd love to hear from you.
None of the major card networks except for American Express validate cardholder name. The Address Verification Service (AVS) also only validates numeric values (so if your address is 123 Main Street, 123 Maple Ave will return a matching response)
Having worked around payments, I can guarantee you that card networks do check the Card Holder name. Better yet, they can match against first name, last name and middle name to adjust the risk rating of individual transactions.
Albeit, this is rarely used to block payments, because if they stopped payments when customers didn't put their middle name the exact way it's written on their card, nobody would be able to pay online.
It’s up to the merchant to decide. You can ask for as little as card number and expiry. All up to the merchant based on how they configure their payment processor
There is no error code that denotes invalid name. Sure the banks gateway fraud detection can decline auth(most don’t), but there would be no way to communicate back to the merchant that the customers needs to check the spelling of the name. I’ve also never seen it when I ran technology at a e-commerce startup that did millions of transactions of month.
I think the claim is that credit card processors don't validate names at payment time. Back before KYC became a thing you could sign up for a credit card with whatever name you preferred. I think it's a bit more strict these days.
That feature is a configurable option (at wildly variable strengths) that is set up by the merchant when they are setting up their payment gateway. All the CC processors I have worked with provide these varying levels of Name/Address strictness.
Was always wondering about that, only occasionally misspelling a letter here or there to see if a transaction would get approved. Can anyone corroborate?
I don't buy this explanation. You need to full control over the screen's framebuffer to render an image?
Even if your architecture is so hosed that you are screencap'ing the actual screen to get an image to ship over a network connection … multiple people thought that tradeoff with security was worth it?
> You need to full control over the screen's framebuffer to render an image?
No, but you do need the ability to render in the background, and apps aren't allowed to do any GPU-based rendering in the background (you can't touch an OpenGL context, and while I haven't actually confirmed this I assume you can't touch a Metal one either). This entitlement probably let them skip that restriction to do fast rendering in the background.
Apple Watch Series 0 is possibly still not capable of rendering maps quickly and has to rely on a companion device. I guess Apple would have to leave this entitlement for Uber until the Watch Series 0 reached end of life five years after last selling them. Which would be quite the security risk.
If you use standalone accounts, then the liability is with Stripe. With managed accounts you're collecting all this information, Stripe charges an additional .5% and financial liability switches to you if Stripe cannot debit the merchant. I'm not saying one shouldn't be responsible for it, but it is a difference.
I would argue that the .5% you are paying to use managed accounts would include some sort of "insurance" against fraudulent merchants especially since one would hope Stripe is providing platforms with a similar level of verification compared to standalone accounts.
Ideally platforms would be aware of the differences and make the best decision based on their risk tolerance and UX goals, but after spending a fair amount of time in Stripe's IRC room in the past, people just want to build something and don't always go into the deep documentation listing some of these gotchas.
