#khris22963

1 messages · Page 1 of 1 (latest)

rare belfryBOT
keen ruin
#

You need to speak to support if you want to use Setup Intents with BACS: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

fossil rover
#

Even in test mode?

keen ruin
#

Yes

fossil rover
#

Is there another way that avoids using SetupIntents?

keen ruin
#

Another way to do what?

fossil rover
#

I need to collect payment details prior to creating a subscription.

#

Here's a bit more background...

#

I’m a UK Stripe newbie, attempting to use Stripe.js and ASP.NET (not MVC or Core) to capture one-off and recurring donations via the site we host for our not-for-profit client.
For one-off payments, I’ve got a prototype working using the following flow:

  • Capture payment amount
  • Redirect to new page where (server-side) I build a payment intent, and add its client secret to a Stripe Payments element.
  • Then when they click ‘pay’, I call stripe.confirmPayment in JavaScript and handle the confirmation etc. in the page called by the return_url
    However, for recurring donations, I’m really struggling.
  • I still want to capture the payment amount, and also a future start date for the recurring payment.
  • I think I need a SubscriptionSchedule for this, rather than a Subscription, as it’s not a trial
  • I think I still need to use a Payments Element, allowing the user to select either Card or BACS direct debit as payment method.

Specific questions:

  • Do I create the SubscriptionSchedule before or after collecting payment details?
  • If before, how do I link it to the Payments element and handle the result server-side in my return_url?
  • If after, what stripe.JS method do I call? Do I still use return_url to process the payment confirmation?
keen ruin
#

Do I create the SubscriptionSchedule before or after collecting payment details?
Yes, if you're against using a trial period.
If before, how do I link it to the Payments element and handle the result server-side in my return_url?
I don't understand the question.

fossil rover
#

Well for one-off, I have a payment intent, and use its client secret in the front end

#

But that doesn't seem to work with recurring payments

keen ruin
#

What doesn't work with recurring payments? It should do. The Subscription (once created) will generate an Invoice for the initial payment with an associated Payment Intent

fossil rover
#

So should I be able to create the payment intent, and use its clientsecret client side with stripe.confirmPayment, even for recurring payments?

#

I want the first payment to be in the future

#

it seems to generate an immediate payment that way even if I use billing_cycle_anchor as a future date

keen ruin
#

You don't need to create a separate Payment Intent, the Invoice generated by the Subscription will automatically have an associated Payment Intent

keen ruin
fossil rover
#

yes, that was how I understood the documentation, and why I started thinking about using Subscription Schedules instead

#

however, I can't see how to collect payment details as there doesn't seem to be a client secret I can pass to the front end

keen ruin
#

There won't be initially no, not until the scheduled start date (i.e. when the Subscription is actually created)

fossil rover
#

sorry if I'm being dumb...

#

the payments will be part of recurring donations given to my not for profit client

#

the donor will specify an amount, and the future start date for the recurring payments, and then I want to present them with the payments element so that they can choose either card or BACS direct debit as payment methods

keen ruin
#

I understand all that

fossil rover
#

ok, so what do I put in options for

elements = stripe.elements(options);
paymentElement = elements.create('payment');
paymentElement.mount('#paymentElement');

#

For the one-off example, it was the client secret from the payment intent

#

but if there's no payment intent, then what?

keen ruin
#

But this won't exist when you create the Subscription Schedule, only after the schedule start date

#

So maybe you listen for customer.subscription.created events in a webhook and then bring the customer back on-session to provide payment details and confirm the Payment Intent

fossil rover
#

???????????

#

I'm sorry, that makes no sense to me

#

the customer has gone to a website to set up a recurring donation, they want to provide payment details and then go away

keen ruin
#

Then a Subscription Schedule isn't going to work for you

#

Instead, use billing_cycle_anchor and proration_behavior: 'none' when you create your Subscription

#

You'll get a pending_setup_intent returned on the Subscription and you can use the client_secret there to collect payment details

fossil rover
#

ok, which brings me back to my question, what do I put in the JavaScript when creating the payments element?

#

as I don't have a client secret

#

or does a subscription have a client secret?

keen ruin
#

You can 'expand' the pending_setup_intent field on Subscription creation

#

And there'll be a client_secret to use

fossil rover
#

ah, so I create the subscription, and it has a pending setup intent, and that has a client secret which I can pass to the front end?

keen ruin
#

Yup!

fossil rover
#

Ok, I think I'm starting to understand... However will I run into the same account issue as I did when I tried to create a setup intent explicitly?

keen ruin
#

You mean for BACS?

fossil rover
#

yes

keen ruin
#

I think you will yes

fossil rover
#

😦

keen ruin
#

But this flow is better regardless as there's less steps involved

fossil rover
#

ok, can you give me any idea what support will need from me to enable me to test BACS in this way?

#

the thing is, it's not my organisation that will be receiving the actual money from these payments... It's my clients who will presumably need their own Stripe account, and will need the same kind of authorisation

rare belfryBOT
keen ruin
fossil rover
#

Gosh. Ok.

#

Ok, I guess I need to get on to Support. Thank you for your time, much appreciated.