feat: cores iap #2783
feat: cores iap #2783
Conversation
capJavert
commented
Apr 24, 2025
•
capJavert
commented
- support for IAP and one time purchases
- refactor apple webhooks file to common to split and reuse common logic
- will work on adding mores tests for IAP flow in next PR after some sandbox testing e2e if needed
| import type { Block, KnownBlock } from '@slack/web-api'; | ||
| import { webhooks } from '../slack'; | ||
|
|
||
| export const isCorePurchaseApple = ({ |
There was a problem hiding this comment.
New file for Cores related and IAP
| import type { Block, KnownBlock } from '@slack/web-api'; | ||
| import { webhooks } from '../slack'; | ||
|
|
||
| const getSubscriptionStatus = ( |
There was a problem hiding this comment.
Mostly code from webhooks file, subscription related
| '/usr/local/share/ca-certificates/AppleRootCA-G3.cer', | ||
| ]; | ||
|
|
||
| const getVerifierEnvironment = (): Environment => { |
There was a problem hiding this comment.
Mostly code from webhooks file, for reuse
| import { readFile } from 'fs/promises'; | ||
| import { isTest } from '../utils'; | ||
|
|
||
| export const verifyAndDecodeAppleSignedData = async ({ |
There was a problem hiding this comment.
New method for decoding both signed data
| @@ -250,30 +69,23 @@ const handleNotifcationRequest = async ( | |||
| return response.status(200).send({ received: true }); | |||
| } | |||
|
|
|||
| // Check if the event is a subscription event | |||
| // NOTE: When adding support for purchasing cores, we must remove this check as it's not a subscription event | |||
| if (isNullOrUndefined(notification?.data?.signedRenewalInfo)) { | |||
There was a problem hiding this comment.
Moved check down only if subscription transaction type
capJavert
requested review from
rebelchris,
omBratteng,
ilasw,
sshanzel,
nensidosari,
AmarTrebinjac and
idoshamun
| requiredRole: CoresRole.User, | ||
| }) === false | ||
| ) { | ||
| throw new Error('User does not have access to cores purchase'); |
There was a problem hiding this comment.
What are we going to do if the user paid and isn't eligible?
There was a problem hiding this comment.
they are blocked on the client side as well, so its mostly another check, we do it on paddle side as well
we would handle it case by case basis, do you want to handle somehow differently?
There was a problem hiding this comment.
but there's also much logic even here that can be reused, am i missing anything?
if we define a common type with all the info from apple/paddle and have one function that checks access, create transactions, etc. it should be better, isn't it? again hard to review this specifically as it's going to change once we go production
There was a problem hiding this comment.
Not really, transaction creation is different on apple and paddle, also detection of product type. I imagine that any new provider will also have it different, so I think its actually nicer for now to keep the logics separate.
What could be done is to create a generic provider interface which would standardize what we expect for each provider, but that requires refactoring how apple and paddle webhooks work now (which is quite different) so it would be separate work from this PR.
There was a problem hiding this comment.
I'll try to add the spec for this in a task, and link back so you can see.
