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)
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.
You can do "payouts" with Stripe Connect. Stripe doesn't have a money transmission license so they can only do a payout when it's tied directly to a charge (like marketplace). You could also take a look at Payoneer.
Only American Express offers name verification to merchants. When it comes to address verification, only the numeric data gets checked. So for an address "123 Main Street" would match "123 Bryant St" as well
I plugged this before, but https://commencepayments.com, which basically acts as a server for a Stripe integration which is pretty neat for people who don't have access to their server-side code. Total Processed volume has exploded over the last couple months (Jan did 4x Dec, and Feb did 2x Jan, with March looking on track to beat Feb).
So with the new growth, looking to add a bunch of cool new features, like iOS / Android library, ACH support, and once Braintree opens the necessary API, Braintree support.
True, though to some extent I'd expect the moderation and reviews of people on Github or apt would be stronger than that of the average wordpress user.
There was a popular (4000+ active installs) Wordpress plugin for Stripe that up until recently (read a week ago) wasn't PCI compliant. I wouldn't be surprised if this sort of thing is more common than just one or two rogue plugins (maybe not as bad as stealing admin credentials, but at a minimum doing things that most people would not consider secure). I would think as a large portion of Wordpress users just download and install which ever plugin looks popular and doesn't verify / validate the actual code.
"Paypal indicated that UnoTelly is not allowed to provide services that enable open and unrestricted internet access."
I don't agree with that intreptation, I'm assuming that the Paypal ToS (like many payments providers) has a line that states you cannot use the service to provide services that enable or facilitate copyright / intellectual property infringement. Accessing Netflix where they are not allowed to stream content due to copyright law would be an infringement.