feat: add getPurchaseInfo to Payment providers
#1466
Conversation
This is the first part of adding a functional interface to payment providers so that other packages and apps can generically do payments actions.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
just in TJS for now, the only place we are using the Stripe Provider at the moment
| @@ -7,7 +7,7 @@ import { | |||
| } from '@skillrecordings/commerce-server' | |||
| import {nextAuthOptions} from '../auth/[...nextauth]' | |||
|
|
|||
| const paymentOptions = defaultPaymentOptions({ | |||
| export const paymentOptions = defaultPaymentOptions({ | |||
There was a problem hiding this comment.
export the paymentOptions so that other pages in TJS can use them
| const purchaseInfo = await stripeData({ | ||
| checkoutSessionId: session_id as string, | ||
| }) | ||
| const purchaseInfo = await paymentProvider.getPurchaseInfo(session_id) |
There was a problem hiding this comment.
replace stripeData call with getPurchaseInfo via the payment provider
| const {stripeChargeId} = await stripeData({ | ||
| checkoutSessionId: session_id as string, | ||
| }) | ||
| if (session_id && paymentProvider) { | ||
| const {chargeIdentifier} = await paymentProvider.getPurchaseInfo(session_id) |
There was a problem hiding this comment.
replace stripeData call with getPurchaseInfo via the payment provider
| const token = await getToken({req}) | ||
| const {getPurchaseDetails} = getSdk() | ||
|
|
||
| const paymentProvider = paymentOptions.providers.stripe |
There was a problem hiding this comment.
We are still defaulting to stripe here. I need to figure out how we are going to differentiate in general when they land on the welcome page that they were directed here via a Stripe vs Paypal purchase so that we look up purchase info with the correct provider.
There was a problem hiding this comment.
we have some control over the callback url with stripe so
success_url: `http://yoursite.com/order/success?session_id={CHECKOUT_SESSION_ID}&provider=${provider}`
would probably work
lemonsqueezy has similar (didn't look to closely) https://docs.lemonsqueezy.com/help/products/button-link-variables
| usedCouponId: z.string().optional(), | ||
| }) | ||
|
|
||
| export const PurchaseInfoSchema = z.object({ |
There was a problem hiding this comment.
get types flowing for the purchase info
| type PaymentProviderFunctionality = { | ||
| getPurchaseInfo: (checkoutSessionId: string) => Promise<PurchaseInfo> | ||
| } |
There was a problem hiding this comment.
the first piece of payment functionality moving into the umbrella of payment providers, additional pieces will be added to this type which the different payment providers conform to
| @@ -23,19 +61,6 @@ export type PaymentOptions = { | |||
| } | |||
| } | |||
|
|
|||
| // define providers here for now, | |||
| // but eventually they can go in a `providers/` directory | |||
| export const StripeProvider: StripeProviderFunction = (config) => { | |||
There was a problem hiding this comment.
Now that this is expanding, moving it to its own module
| const {stripeCtx} = options | ||
|
|
||
| const purchaseInfo = await stripeData({checkoutSessionId, stripeCtx}) | ||
| const purchaseInfo = await options.paymentProvider.getPurchaseInfo( |
There was a problem hiding this comment.
using the payment provider in here to getPurchaseInfo, though you'll notice above that the stripeData function still exists. that is because many of the apps still rely on it. once I've configured payment providers in each of those apps, they will be able to switch over to the new implementation and we can ditch stripeData.
| const { | ||
| stripeCustomerId, | ||
| customerIdentifier, | ||
| email, | ||
| name, | ||
| stripeProductId, | ||
| stripeChargeId, | ||
| stripeCouponId, | ||
| productIdentifier, | ||
| chargeIdentifier, | ||
| couponIdentifier, | ||
| quantity, | ||
| stripeChargeAmount, | ||
| chargeAmount, | ||
| metadata, |
There was a problem hiding this comment.
account for some variable renaming from purchaseInfo because we are trying this as provider agnostic info
| const getStripeClient = (paymentOptions: PaymentOptions | undefined) => { | ||
| return paymentOptions?.providers.stripe?.paymentClient | ||
| } | ||
|
|
||
| const constructFallbackStripePaymentOptions = ( | ||
| stripe: Stripe, | ||
| ): PaymentOptions => { | ||
| return defaultPaymentOptions({ | ||
| stripeProvider: StripeProvider({defaultStripeClient: stripe}), | ||
| }) | ||
| } |
There was a problem hiding this comment.
this module processes stripe webhooks, so it can reach directly for the stripe client.
since most of the apps are still using the stripe module instead of configuring payment providers, this other helper function makes it easy to fallback on that client while conforming to the new provider-based API
| const token = await getToken({req}) | ||
| const {getPurchaseDetails} = getSdk() | ||
|
|
||
| const paymentProvider = paymentOptions.providers.stripe |
There was a problem hiding this comment.
we have some control over the callback url with stripe so
success_url: `http://yoursite.com/order/success?session_id={CHECKOUT_SESSION_ID}&provider=${provider}`
would probably work
lemonsqueezy has similar (didn't look to closely) https://docs.lemonsqueezy.com/help/products/button-link-variables
…apter-interface-which-defines-core
kodiakhq
bot
deleted the
jbranchaud/sks-84-create-payment-provider-adapter-interface-which-defines-core
branch
This is the first part of adding a functional interface to payment
providers so that other packages and apps can generically do payments
actions.