#saeven-js

1 messages · Page 1 of 1 (latest)

lofty obsidian
#

@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

quasi portal
#

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.

#

but it has a deprecation notice...

lofty obsidian
quasi portal
#

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".

lofty obsidian
#

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

quasi portal
#

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.

lofty obsidian
#

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?

quasi portal
#

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.

lofty obsidian
#

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

quasi portal
#

thanks for your help, truly appreciated.

#

🙏

lofty obsidian
#

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