#jaymuk-subscription-save-pm
1 messages · Page 1 of 1 (latest)
Hello 👋
I don't think that's something that we support at the moment.
An active subscription needs a payment method so that it can be renewed
You could just accept a one time payment for the first year and then create subscription starting next year
hmm issue with that approach is that our system relies on the user having a stripe_subscription
something that worked by accident was that we used a one-time price to create the payment link, but on the fulfillment side, we created a subscription with our 'recurring' price
but that might in fact be one way we can achieve this. I'm just trying to see whether we might be shooting ourselves in the foot by doing it this way
yeah I'm not sure as I haven't tested any alternatives for this myself.
but on the fulfillment side, we created a subscription with our 'recurring' price
How exactly are you handling "fulfillment". Are you relying on webhooks and calling the API?
yeah exactly.. we get the one-time payment, and then setup a negative invoice item to offset the first invoice
but accidentally used the recurring price, instead of the one-time price, to create the subscription
once I realised that, I tried to use one-time price and now realising that subscriptions don't support that
I guess my question is.. does it matter that we use one-time price for the payment link, and a recurring 'price' for the subscription?
@sudden stratus do you have any thoughts on this?
I haven't tested this myself but an alternative that I can think of would be
- Accept a one-time payment with PaymentLink for the first year
- Listen for the webhook event for successful payment
- Then create a new subscription by calling the API and set trial_days to
365
The subscription with a trial will generate a $0 invoice which doesn't need to be paid, in which case subscription will be active
ah - thanks! that's an interesting alternative
Yeah I'd recommend giving it a go in test mode to be 100% certain
Sorry to bother you again @sudden stratus (hopefully the last time for now ;p )
is your suggestion any different (in practice) from: instead of using trial_days, creating a negative invoice item to offset the cost of the first invoice payment?
In both cases we'd still be using a different price (although for the same amount) for the payment link vs the subscription
I actually already have it working this way
Offering a trial is the recommended way to kick off the subscription without requiring payment. that's what we generally suggest.
I'm not super sure about adding a negative invoice item to offset the first invoice as I haven't tested it.
Ah interesting - I think trial_days is a neat solution. Although in our case, I think the negative invoice item gives us a means of transferring the one-time payment (from someone else) to the recipient user (who will be getting. subscription to our product) and tracking some metadata