2 ms·

Seriously look at other payment processors. You are overthinking this - if you have to use game theory and uncertainty to plan your relationship with a vendor

Seriously look at other payment processors. You are overthinking this - if you have to use game theory and uncertainty to plan your relationship with a vendor (instead of picking up a phone or sending an e-mail to ask or solve your issues), you need to find a new vendor.

joecot 4y ago
Mostly, just use multiple providers. There's no reason to put all your eggs with Stripe. Setting up with Paypal, Google Payments, Amazon Payments, etc, requires essentially no business overhead. Just the extra overhead of needing to setup multiple payment providers in your software. Use multiple providers, if one shuts you down you still have other options. When you're large enough that it makes financial sense, apply for your own merchant account and use a processor like Authorize.net for that too.
- Bilal_io 4y ago
  The issue would be subscriptions if I am not mistaken. If I allow a user to pay a monthly subscription, I am obviously going to depend on Stripe or another provider to hold the information for me, and if they deactivate my account, then I am screwed, a fallback would involve having the user come back in and give you permission to charge their other account (say stripe bans you, you want to use PayPal as a fallback). It's just bad.
  - joecot 4y ago
    Yes, this is a risk. Which is why instead of putting all your subscriptions towards one company, it is a good idea to balance your subscriptions across providers. That way, you might lose some customers or have to ask them to come sign up again, but you don't lose all or even most of them.
    - TrickardRixx 4y ago
      Is it an option to tokenize the recurring payments across both providers, but only charge on one provider at a time?
      - zhfliz 4y ago
        at least with paypal it's possible to allow future deductions without explicit authorization through paypal every time. i don't know if their terms allow this to be used for recurring payments, it is used e.g. for services such as steam and humble bundle, where you can choose to remember your payment method.
      - joecot 4y ago
        Yes but it's complicated. * It's possible that you could tokenize to each provider before making a transaction. But you'd need to see if the provider has a timeout on those tokens if you don't actually make a transaction with it. You'd also need to make sure your processor will even allow you to connect to them directly and authorize a transaction with that token later without consumer interaction. * You can tokenize the card number and expiration, but not the CVV. Some cards you would be able to get an auth without a CVV, with a slightly higher processing fee (that may or may not get passed on to you). But some will just get declined without the CVV. You are not allowed to store the CVV. * You're really supposed to get the CVV for any transaction that's an initial transaction. This is a recurring transaction, but since you are changing the agreement (by moving providers and a completely different merchant account), it's really a new initial transaction. Your customer will see a different descriptor on their credit card statement, they may complain, it could end up being a whole thing. And if you're worried about needing to use multiple providers, you don't have your own merchant account, so the bank doesn't come to you, they go to Paypal, or Stripe, etc. Now you have to explain to them why there's a new transaction with no consumer interaction, if they contact you to ask at all before shutting you off. * Unless you're using a plugin like Stripe's for every processor, quickly doing a request to your processor directly in the user's browser and submitting each of the tokens to yourself, doing this would require you to at least accept and transmit credit cards yourself, not sending the consumer onto the processor's site to fill it out. You are now transmitting credit card data yourself, which means you'll have to go through the PCI Compliance process. It's a self-assessment, and you can skip a lot of steps if you're at least not storing the card number (which you probably should not), but it still a bit of an arduous process. No one's going to check you on this unless there's some sort of breach, but you should still definitely do it.

joecot 4y ago

Mostly, just use multiple providers. There's no reason to put all your eggs with Stripe. Setting up with Paypal, Google Payments, Amazon Payments, etc, requires essentially no business overhead. Just the extra overhead of needing to setup multiple payment providers in your software. Use multiple providers, if one shuts you down you still have other options. When you're large enough that it makes financial sense, apply for your own merchant account and use a processor like Authorize.net for that too.

Bilal_io 4y ago
The issue would be subscriptions if I am not mistaken. If I allow a user to pay a monthly subscription, I am obviously going to depend on Stripe or another provider to hold the information for me, and if they deactivate my account, then I am screwed, a fallback would involve having the user come back in and give you permission to charge their other account (say stripe bans you, you want to use PayPal as a fallback). It's just bad.
- joecot 4y ago
  Yes, this is a risk. Which is why instead of putting all your subscriptions towards one company, it is a good idea to balance your subscriptions across providers. That way, you might lose some customers or have to ask them to come sign up again, but you don't lose all or even most of them.
  - TrickardRixx 4y ago
    Is it an option to tokenize the recurring payments across both providers, but only charge on one provider at a time?
    - zhfliz 4y ago
      at least with paypal it's possible to allow future deductions without explicit authorization through paypal every time. i don't know if their terms allow this to be used for recurring payments, it is used e.g. for services such as steam and humble bundle, where you can choose to remember your payment method.
    - joecot 4y ago
      Yes but it's complicated. * It's possible that you could tokenize to each provider before making a transaction. But you'd need to see if the provider has a timeout on those tokens if you don't actually make a transaction with it. You'd also need to make sure your processor will even allow you to connect to them directly and authorize a transaction with that token later without consumer interaction. * You can tokenize the card number and expiration, but not the CVV. Some cards you would be able to get an auth without a CVV, with a slightly higher processing fee (that may or may not get passed on to you). But some will just get declined without the CVV. You are not allowed to store the CVV. * You're really supposed to get the CVV for any transaction that's an initial transaction. This is a recurring transaction, but since you are changing the agreement (by moving providers and a completely different merchant account), it's really a new initial transaction. Your customer will see a different descriptor on their credit card statement, they may complain, it could end up being a whole thing. And if you're worried about needing to use multiple providers, you don't have your own merchant account, so the bank doesn't come to you, they go to Paypal, or Stripe, etc. Now you have to explain to them why there's a new transaction with no consumer interaction, if they contact you to ask at all before shutting you off. * Unless you're using a plugin like Stripe's for every processor, quickly doing a request to your processor directly in the user's browser and submitting each of the tokens to yourself, doing this would require you to at least accept and transmit credit cards yourself, not sending the consumer onto the processor's site to fill it out. You are now transmitting credit card data yourself, which means you'll have to go through the PCI Compliance process. It's a self-assessment, and you can skip a lot of steps if you're at least not storing the card number (which you probably should not), but it still a bit of an arduous process. No one's going to check you on this unless there's some sort of breach, but you should still definitely do it.