#jogui-3ds
1 messages · Page 1 of 1 (latest)
Sure, here: sub_1KidYtHFmluYEPgf2swYvNW3
Um a SetupIntent will always ends up with 0 eur displayed, because ... it's a SetupIntent
For returning user, is that your business requirement to charge them 9.99 eur?
Let me think of a flow that makes sense
Yes, it's the typical subscription flow of a Premium yearly service.
People that never got the Premium has 14 days free trial, others pay the sub
I was also wondering this, and I feat i will have to implement a different purchase flow for returning users where I use payment intent or something like this from Stripe Elements directly
How did you charge them for 9.99 eur? Creating a PaymentIntent in backend and just process it?
Yeah that's the ideal approach. You create a 9.99 eur PaymentIntent, confirm in frontend for 3DS (it would display 9.99). Then in backend you take the PaymentMethod attached then create a trial Sub with that PaymentMethod
What amount is displayed is purely decided by what amount that PaymentIntent/SetupIntent has. In the case of SetupIntent it will always be 0
I cannot use PaymentIntent for trials, thats why our implementation uses a setupIntent, and on ACK, the backend creates the subscription
public static Subscription createSubscriptionForInvoice(String priceId, Customer customer,
String paymentMethodId, Map<String, String> metadata, String taxId, boolean addAutomaticTax,
boolean isTrialAvailable)
throws StripeException {
SubscriptionCreateParams.Builder subCreateParams = SubscriptionCreateParams
.builder()
.setCustomer(customer.getId())
.addItem(
Item.builder()
.setPrice(priceId)
.build()
)
.setPaymentBehavior(PaymentBehavior.ERROR_IF_INCOMPLETE)
.setDefaultPaymentMethod(paymentMethodId)
.addAllExpand(List.of("latest_invoice.payment_intent.payment_method",
"latest_invoice.total_tax_amounts.tax_rate", "default_payment_method"))
.setProrationBehavior(SubscriptionCreateParams.ProrationBehavior.NONE);
if (StringUtils.isNotBlank(taxId)) {
subCreateParams.addDefaultTaxRate(taxId);
} else {
subCreateParams.setAutomaticTax(AutomaticTax.builder().setEnabled(addAutomaticTax).build());
}
if (isTrialAvailable) {
subCreateParams.setTrialPeriodDays(TRIAL_DAYS);
}
if (MapUtils.isNotEmpty(metadata)) {
subCreateParams.setMetadata(metadata);
}
return Subscription.create(subCreateParams.build());
}
this is the code that creates the subscription, after the SetupIntent has been success and the customer has the payment method linked
Yeah I see. If you create a PaymentIntent and confirmed it in client-side, you can also get its paymentMethodId, right? How about just use that Id to this very same function?
Can you elaborate a little more? I dont follow your point
if I use a payment intent and confirmed it in client-side, and pass that paymentMethodId here , won't I charge twice the Returning User?
I don't think so, since this code creates a trial Subscription and will use the PaymentMethod for its next cycle. But please be sure to test it
Sorry to bother you orakaro, but I think we are talking about two different use-cases
I mean, returning users don't have trial at all, they start inmadietly the subscription. If I use a paymentIntent in the frontend, I can't use this method, because would charge again for the subscription, right?
Oh the returning users don't have trial?
Can I confirm that 9.99 eur is the actual Subscription one cycle price?
In this case I think it would be much clearer if you separate 2 flows, and consider them as 2 separated integration paths
Yeah, I will do that
Yes, returning users are not elegible for trial
Yes, we have a product with two plans: 1 year for 9,99€ and 3 months for 4,99€
Good luck!