#bruno777-paymentlinks

1 messages · Page 1 of 1 (latest)

wispy wyvern
celest brook
#

ok, we are far from the real nocode

#

Thanks

#

Isn't there a way to give you 3 urls with variables that circulate for these 3 types of events without having to do as many actions to achieve the same result?

wispy wyvern
#

I don't know what you mean exactly. "circulate"?

#

and yes you need code at some level, you mention assigning access to your product to a customer, that is code in your backend user management system, which you would connect to actions on your Stripe account by listening to webhooks on your server that manages that system. I'm not sure how else it would work.

celest brook
#

I would have found it much simpler by giving you:
1/ A URL to trigger
2/ My internal customer ID
4/ A security key for this client (which I determine)

You trigger this url with:
1/ Your security key (which may change from time to time via the dashboard)
2/ The status (success, error)

wispy wyvern
#

that's fair, but that's not very generic

#

merchants of all kinds and businesses use Stripe, lots use it for shipping physical products and not access to a system like you mention

#

so we can't really build a generic fits-all solution, so it mainly comes down to you as the merchant writing the custom code to connect the payment reconcilation to your business needs. But I do agree in general, and in the longer term we will likely make this side of things much better, it's just early days(PaymentLinks only launched earlier this year).

celest brook
#

And without going through a webhooks...
After configuring my products.

I can't make a simple API call with the right variables that returns me success or failure?

hollow lantern
#

Hi! I'm taking over this thread.

celest brook
#

Hi! Thankls.
If I understood correctly, it should be quite easy for me to transform my classic PaymentIntent into a recurring subscription?

#

Currently I store the cus_ after my non-recurring payments

hollow lantern
#

to transform my classic PaymentIntent into a recurring subscription
What do you mean by this?

celest brook
#

I have already done a full Stripe integration in my context.

The only thing that changes is that we have a credit recharge system (one shot, the recurrence is decided by our customers).

I would now like to offer a subscription, therefore, from now on, the recurrence is mandatory.

I would like to limit the integration time, so if possible.
1/ Duplicate and adapt our current payment form (based on a PaymentIntent::create).
2/ Make a CRON which, by API, only checks the current subscriptions (one by one for those who are close to the renewal date)
3/ By API be able to stop a subscription

hollow lantern
#

Do you want to use Stripe Subscription feature (strongly recommended), or do you want to make your own subscription logic with crons and PaymentIntents?

celest brook
#

My own logic, I think, will be faster for us. Especially since we are in the pivot phase.

hollow lantern
#

That's not what we recommend and it's going to be a lot of work to handle all cases, but that's possible yes. - First create PaymentIntents with setup_future_usage: off_session, to save the card details for later. And then use CRONS to charge the existing PaymentMethod at regular intervals.

celest brook
hollow lantern
#

I'm confused. Earlier you said you don't want to use Stripe Subscription, but now you point to the API endpoint to retrieve Stripe Subscriptions.

celest brook
#

In other words, I didn't see in the doc how Stripe returns the su_ to me once my client has made his first payment.

#

It's normal, I take your answers into account.
And, as indicated, I seek before the shortest possible integration time.

hollow lantern
#

Let's take a step back because I'm lost.
The simplest way to create subscription with Stripe is what was discussed earlier in this thread: use Payment Links to create subscriptions, and the listen to webhooks events to fullfil the order.

celest brook
#

For me, the easiest way is to make nocode with the payment links of my products to collect payments.

Then to check on my side that they are well subscribed then renewed via CRON/API.

To do that, in view of the elements that you sent to me, thank you very much, I am missing a single piece of information.

How to trace the user after he is clicked on the payment link in order to build my query via API?

hollow lantern
#

then renewed via CRON/API.
I don't understand this part. If you create Stripe Subscriptions, they will renew automatically. There's nothing to do on your end.

#

How to trace the user after he is clicked on the payment link in order to build my query via API?
To know when a Payment Link payment is completed, you need to listen to the checkout.session.completed event.

celest brook
#

With your system, if I understand correctly, it is:
1/ either permanent links & webhook
2/ Either all in code with this: https://stripe.com/docs/api/subscriptions/list

It's a pity, that there is not an intermediary.
It would suffice to send me the variable after the permalink so that I can control that subscriptions are made freely via API.

Stripe API reference – List subscriptions – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

I'm not hiding from you that I'm going to look on the side of Paypal, your process is too cumbersome.

hollow lantern
#

There is some miss-understanding here. There are many ways to create subscriptions with Stripe:

celest brook
hollow lantern
#

You should be using webhooks when creating subscriptions to track their status.

silk haven
#

Hi there 👋 I'm jumping in as my teammate needed to step away, please let me know if there are any outstanding questions that I can help address.

celest brook
#

Hi, and thanks soma.

If I summarize what we intend to do:
1/ We start from our standard payment page which allows us, among other things, to recover the cus_
With this: \Stripe\Customer::create

2/ We replace our PaymentIntent with a subscriptions->create and we get the sub_
With this: https://stripe.com/docs/api/subscriptions/create

3/ Thanks to the sub_ we freely check that the subscription has been renewed
With this: https://stripe.com/docs/api/subscriptions/list

4/ And we can easily offer our customers to cancel or change their subscription by manipulating this:
https://stripe.com/docs/api/subscriptions/cancel

Does it seem ok to you? Can we get started like this? I've not forgotten anything ?

silk haven
#

Sorry, but I'm a bit confused, so let's walk through it.

#

In Step 1, if you're using a Payment Link to allow your customers to start their subscriptions, then that process will create Customer objects already and you don't need to explicitly create them yourself.

#

Oh, or are you trying to map out how to complete this flow without using Payment Links?

celest brook
#

Ok, for step 1 it is simply to mean that we are starting from an already integrated payment form to reduce development time.

So, in this framework, we will replace the part of code that triggers: PaymentIntent::update then the PaymentIntent::retrieve

By one: subscriptions->create

silk haven
#

Gotcha, I'm not sure how your current payment page functions so I won't be able to comment too much on what would need to change about it in order to adapt it to work for Subscriptions.

When working Subscriptions you will need to both create the Subscription and process the payment for it (unless you're planning to use free trials) so your payment page will still need to be able to process a Payment Intent.

This guide does a good job of walking through the full process of creating a Subscription with a custom payment page:
https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements

Build a subscriptions integration

Create and manage subscriptions to accept recurring payments.

celest brook
#

OK good. I think it's pretty clear to me now, I'll test it all out.
Thanks

silk haven
#

Happy to help!