#saeven-js
1 messages · Page 1 of 1 (latest)
@quasi portal if you want to collect card details, you would probably want to use stripe.js i.e. the Payment Element or Checkout to collect the card details
i'm not too sure what you meant by supporting this kind of flow without leveraging Stripe's javascript
Thanks for your reply!
Reading the docs, there were so many options, and several seemed to rely on Stripe-provided javascript components.
The app currently uses a merchant account, which yields a kind of token that can be used for recurring charges.
I don't store the card details on my shores, and I see that Stripe offers something very similar.
but what I can't find within Stripe
is a means to say very plainly: "Charge this customer $X" and then have everything necessary to charge them another $Y as they add products to cart, or change services. My app takes care of pro-rata and coupons and credits and so forth; I can't pawn these off to Stripe's subscription system, etc.
The closest thing I've found, seems to be: https://stripe.com/docs/payments/accept-a-payment-charges
but it has a deprecation notice...
when you use the Payment Element or Checkout to collect card details, Stripe will take care of the tokenization and return a token which you can use for recurring charges. e.g. https://stripe.com/docs/payments/save-and-reuse
Thanks, so I had read this Payment Element system, and I read somewhere, that it can be used to charge a client "At most once".
it's possible to use it to save a card for future use also. You can read through the different options in that guide - select the appropriate tab e.g. Prebuilt Checkout page or Custom payment flow
Is there a world where the flow can be:
- browser posts card data to server,
- server performs call to stripe to set up the customer
- a token is retrieved
- token can be used anytime to issue charges
the exact use case, is for server provisioning, like AWS. Client pays up front for a reservation, and they can scale their usage up/down throughout the month - and pro-rata gets applied at every step. So, each operation can result in a charge or a credit.
Don't want to bother them for a card each time. That'll lead to crushing attrition.
that's what the guide mentions though i.e. save a card once and you can use it for future payments
or do you mean that you want to tokenize the card via API?
so I can set up an intent, charge them immediately, and continue to reuse the intent over and over?
from what I'd gathered, the intent was a one-time thing.
if you're using PaymentIntents, you can use the setup_future_usage=off_session and define a Customer id so that the PaymentMethod will be saved to the Customer after payment. You can then use that PaymentMethod id for future off_session payments
For context, if you want to collect the raw credit card numbers in your custom form and then use the Stripe API directly to tokenize the cards. We actively discourage you from doing this because by handling raw card numbers directly you become subject to the full PCI compliance standards. In your case this means you’d have to submit a SAQ D form annually to prove that you are PCI compliant [0]. It’s a 40 page form and not a headache most people want to be dealing with.
[0] https://stripe.com/docs/security/guide#validating-pci-compliance - select the tab API direct
by the way, i also wanted to add on
If you're likely to have india issued cards, you're going to need to include mandate options when creating a PaymentIntent or SetupIntent. If it's an india issued card, you need to include a mandate id when creating an off_session payment : https://stripe.com/docs/india-recurring-payments