#Sophia Wong

1 messages · Page 1 of 1 (latest)

daring oxideBOT
median plinth
#

You can't associate a Payment Link with an existing subscription. The Payment Link would create any subscription upon success

whole wedge
#

Hmmm, I'm not sure. I need to provide subscription service for users, let them pay on my site, and then check subscription-status. Would you give the simpliest way to accomplish that?

#

Here is what I did earlier today:

  1. prepare my product and price. 2. create customer via API in stripe for the ones who want to purchase our service. 3. use customer_id and price_id to create a checkout session with subscription mode. 4. redirect user to checkout session payment url 5. (here my problem comes) I should record the subscription_id so that I can check if this user has paid and then let him/her access our products, right? I must use a webhook to get a subscription_id ?
#

webhook seems a little complicated to use 😅 So I'm trying to find a simpler way.
Now I'm working with Codeigniter - a PHP framework.

median plinth
whole wedge
#

Cann't I just create a subscription and check it's status afterwords? If the subscription is not active, for example, incomplete or past-due , I can remind user and show them a payment link.

median plinth
#

Sure, but then what happens if a future recurring payment is declined or failed? Or a customer cancels their subscription? How are you updated about that so that you can revoke access?

#

If you don't want to manage the development overhead for webhooks, look at using something like Zapier instead

#

But you can't really get around using webhooks/events with a Stripe integration, especially for subscriptions

whole wedge
#

"if a future recurring payment is declined or failed? Or a customer cancels their subscription?", in these cases, status of the subscription should be abnormal, I think I just need to check the status and decide if user is allowed to access products. This logic sounds simple. Is it wrong? If people want to repurchase it after they cancel or reject a exist subscription, I can schedule a new subscription for them.

median plinth
#

I think I just need to check the status and decide if user is allowed to access products.
Sounds like a pretty manual process to me!

whole wedge
#

I don't have enough time, so I want it to be as simple as possible. If I'm demanded to handle the events, I'll dig in some more. But not necessary for now.

median plinth
#

Then how can I help?

whole wedge
#

If I do it in this way like I just said. Should I create a subscription at first, and then get last_invoice_id, and then manage to get a payment link? Lots of thanks for your time. I really appretiate!

median plinth
#

I thought you were using Checkout?

whole wedge
#

Right. Currently I build checkout session for subscription. But I can't get subscription_id from API return data. I was told to use webhook to get subscription_id, which I'm trying to get around now.... 😂

median plinth
#

API return data
Which is what? What object?

whole wedge
#

$data = [
'customer' => $params['customer_id'],

        'mode' => 'subscription',
        ....
    ];

    $checkout_session = \Stripe\Checkout\Session::create($data);
    log_message('error', print_r($checkout_session, true));
#

the create checkout session API

median plinth
#

Yes, because at that point you've only created the session. The customer has completed it

#

There's no subscription at that point

whole wedge
#

yes. So I'm trying to find another possible way like creating subscription first so that I can get a subscription_id directly.

median plinth
#

This is why you listen for checkout.session.completed events, which will include the associated sub_xxx ID you need

median plinth