Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WEB-2010] Split the checkout flow into two parts #305

Open
wants to merge 20 commits into
base: fon/new-sdk-views
Choose a base branch
from

Conversation

vicfergar
Copy link
Contributor

@vicfergar vicfergar commented Feb 5, 2025

Motivation / Description

This PR changes the checkout flow by using the two new endpoints:

  • /checkout/start: Called right after entering the billing email. Returns the operation ID and the necessary configuration to initialize the Stripe Elements component.
  • /checkout/complete: Called after submitting the payment method form, it creates the corresponding intent (SetupIntent or PayentIntent) and returns the client secret.

Note: All the necessary backend changes have been already shipped

Changes introduced

b6cae2f - chore: Improve error handling during payment info collection
8b3a7e9 - fix: Set font family in Stripe Elements
ae53ece - chore: rename data field to gateway_params
d3a4daf - chore: Remove unnecessary fields from CheckoutCompleteResponse
7917239 - feat: Pick elements_configuration from the checkout start response
6204845 - chore: Remove environment var VITE_STORYBOOK_RESTRICTED_SECRET
429630d - chore: Fix purchase flow stories
32fe846 - chore: fix unit tests
48ea8b6 - feat: Replace the PurchaseEndpoint with CheckoutStartEndpoint and CheckoutCompleteEndpoint
209c078 - chore: Remove svelte-stripe dependency

Linear ticket (if any)

Additional comments

@vicfergar vicfergar requested a review from a team February 5, 2025 22:56
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch 2 times, most recently from f2696f6 to 37e81be Compare February 5, 2025 23:09
@@ -19,8 +19,6 @@ const config: StorybookConfig = {
...config,
VITE_STORYBOOK_PUBLISHABLE_API_KEY:
process.env.VITE_STORYBOOK_PUBLISHABLE_API_KEY || "",
VITE_STORYBOOK_RESTRICTED_SECRET:
process.env.VITE_STORYBOOK_RESTRICTED_SECRET || "",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This env var is no longer needed. With the new flow, we don't need a payment_intent or setup_intent to render the payment form 😄

@@ -92,7 +92,6 @@
"storybook": "^8.5.0",
"svelte": "^5.12.0",
"svelte-check": "^4.1.1",
"svelte-stripe": "^1.3.0",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this third-party library and initialized the stripe elements as recommended by Stripe.

@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from 37e81be to 42589e7 Compare February 6, 2025 08:51
Comment on lines -119 to -123
if (result.next_action === "completed") {
lastError = null;
currentView = "success";
return;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was unreachable code, since next_action is always set to collect_payment_info by the backend

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question:
Did we break this unreachable code for some previous version by always returning "collect_payment_info"?

When was completed being returned?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct Nicola, the old endpoints (/subscribe and /purchase endpoints) are kept untouched and will return the field collect_payment_info.

I tested all of this in a canary using the published version of the SDK before shipping the BE changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My question was related to the completed value.

When was that value returned?
In what scenario?

I understand that "recently" we updated to always return collect_payment_info my question is:

Did we break older version of the sdk that supported completed when we stopped sending it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I’m not following. completed is not returned by the backend, even before any deferred flow changes were shipped. I don’t think that status was ever used, IIRC

This PR should not break the existing flow. I tested the live WPL version before shipping the backend changes, and no issues were detected.

Comment on lines 152 to 155
paymentMethodTypes: ["card"],
setup_future_usage: "off_session",
amount: productDetails.currentPrice.amountMicros / 10000,
currency: productDetails.currentPrice.currency.toLowerCase(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these parameters should match the settings from the PaymentIntent/SetupIntent, I was considering including them in the CheckoutStart response. Wdyt @RevenueCat/web?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, the risk is that the productDetails.currentPrice.amountMicros might be different from the one show at the time of downloading the product.

However it is worse if we show one price and then charge another one. So yes, returning the latest up to date price for the product from the backend it's a good idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this to retrieve these values from the start purchase response so that we have more control over them from the backend

@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from f9ecb2e to f5fc27c Compare February 6, 2025 20:37
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from ff2d793 to d1a61b3 Compare February 7, 2025 06:31
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from d1a61b3 to ae53ece Compare February 7, 2025 16:03
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from d9121c4 to b6cae2f Compare February 9, 2025 22:49
@vicfergar vicfergar marked this pull request as ready for review February 10, 2025 08:06
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from ac94730 to 1136121 Compare February 10, 2025 10:54
@vicfergar vicfergar force-pushed the WEB-2010-websdk-invoke-the-new-endpoints branch from 1136121 to 71c033e Compare February 10, 2025 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants