#giles-migrating-api

1 messages · Page 1 of 1 (latest)

void bison
#

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

sonic relic
#

definitely helpful. so is a plan not necessary anymore? I see no reference to it in the examples

void bison
#

Those are now "Prices" and are more or less the same

sonic relic
#

got it. out of curiosity are the plans / subscriptions approaches used in older apis still supported as legacy?

void bison
#

Yep, no issues with that. Old plan IDs can still be used where we expect Price object IDs, too.

sonic relic
#

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.

void bison
#

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?

sonic relic
#

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

soft oriole
#

@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

sonic relic
#

ah ok. so i front load the subscription.

soft oriole
#

Yes!

sonic relic
#

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

soft oriole
#

We replaced the Plan API with the Price API. But they are compatible with each other.

sonic relic
#

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

soft oriole
#

Usually you create Prices (not Plans) to represent your catalog, you don't do this for every subscription

sonic relic
#

great. I'll look into it a little more. appreciate the help!