#giles-migrating-api
1 messages · Page 1 of 1 (latest)
Recurring payments are managed with subscriptions, so i would recommend reading through the docs about that and for example looking at the integration options here:
https://stripe.com/docs/billing/subscriptions/build-subscription
You can integrate fully custom, or what i'd recommend using Checkout (perhaps with payment links), to reduce the work you need to do
There are a number of ways to do this of varying complexity, so it's to you to decide how much you want to build
definitely helpful. so is a plan not necessary anymore? I see no reference to it in the examples
Those are now "Prices" and are more or less the same
got it. out of curiosity are the plans / subscriptions approaches used in older apis still supported as legacy?
Yep, no issues with that. Old plan IDs can still be used where we expect Price object IDs, too.
trying to get a client pci compliant with limited budget but their checkout process on donations is a bit of a mess. trying to clean things up with as little rewrite as possible
good to know. I guess the only issue I'm left with is a recurring donation doesn't even currently hit the paymentIntents api because you create the plan with the amounts in code (originally bypassing charges api). I get the payment from paymentIntents with the correct response but then I'm left to build out the plan / subscription objects.
So, you wouldn't want to create the payment manually first in that case, you'd create the subscription and the subscription via invoice) would collect payment
Do you want an embedded custom flow, or are you happy with a redirect to a hosted Stripe UI to make this easier?
has to be a custom flow
so would the customer still be presented with the payment form with the subscription type setup
i'm assuming yes just trying to wrap my head around it
@sonic relic if you move to the most recent recommended integration path, the way you do it is that you first create the subscription server-side with payment_behavior: 'default_incomplete' to have a Subscription ready but not paid yet. Then you get the corresponding PaymentIntent's client_secret and you confirm client-side with PaymentElement as you collect their payment details
ah ok. so i front load the subscription.
Yes!
does the plan object come into play here as well? our code originally did something like this
if (stripe_account_id (connect api sub customer??) ) {
// create plan with interval info
// create customer
// create subscription with reference to plan->id and customer->id
} else {
// create plan with id attribute 'id' => 'plan-' . $token->id . '-' . date( 'Y-m-d' )
// create customer with reference to plan
}
} else {
// in basic donation (non recurring)
if (stripe_account_id (connect api sub customer??)) {
// create customer
// create charge (referencing customer->id) and (with application fee)
} else {
// create customer
// create charge (referencing customer->id)
}
}
we inherited this so it has been a bit of a lift to get a handle on the original intent here and updating with the latest stripe api for pci compliance
We replaced the Plan API with the Price API. But they are compatible with each other.
ok so I'd create a plan prior to subscription. Process payment intents and then update the subscription. starting to make sense. really appreciate the help here
Usually you create Prices (not Plans) to represent your catalog, you don't do this for every subscription
great. I'll look into it a little more. appreciate the help!