backend-manager 5.0.161 → 5.0.162
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/TODO-2.md
ADDED
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
TODO
|
|
2
|
+
* pdate deps LIKE WF, PP, ETC
|
|
3
|
+
|
|
4
|
+
PAYMENT SYSTEM
|
|
5
|
+
* Ensure attribution is working (utm but also the AD ID shit like from adwords, tiktok ads, meta etc)
|
|
6
|
+
* ensure legacy plan RESOLVING is working
|
|
7
|
+
|
|
8
|
+
payments/reactivate
|
|
9
|
+
* takes a subscription id and reactivates a cancelled subscription. this can only be done if the subscription is still within its billing period, otherwise the user would have to create a new subscription.
|
|
10
|
+
payments/upgrade
|
|
11
|
+
* takes a subscription id and a new plan id and upgrades the user's subscription to the new plan. this can only be done if the user has an active subscription.
|
|
12
|
+
|
|
13
|
+
TEST NEWSLETTER
|
|
14
|
+
POST /admin/cron { id: 'daily/marketing-newsletter-generate' }
|
|
15
|
+
|
|
16
|
+
Payment attribution
|
|
17
|
+
* can you ensure the the user's attribution (utm etc) is assocaited with the purchase
|
|
18
|
+
* mostly i am referring to the payent events sent to GA4, tiktok, meta
|
|
19
|
+
* i think we should make it so if the attribution was set less than 30 days ago (the date is in the attribution) then it counts
|
|
20
|
+
* it shouldbe attached to the payments-orders and then ALL FUTURE EVENTS should send that (thats a good idea right??)
|
|
21
|
+
|
|
22
|
+
Payment disputes
|
|
23
|
+
* automatic dispute handling
|
|
24
|
+
* during bm_cron daily, we should check for open disputes for pypal stripe etc... we should then FILL THEM WITH INFORMATION USEFUL FOR WINNING
|
|
25
|
+
* we should attach USAGE LOGS, IP logs, etc. you should take inspiration from my previous attmept at this (/Users/ian/Developer/Repositories/ITW-Creative-Works/subscription-profile-sync/main/disputes)
|
|
26
|
+
* HOWEVER, i know for a fact i got a lot of it wrong. so JUST USE AS INSPO, you should recreate it full
|
package/package.json
CHANGED
package/src/manager/events/firestore/payments-webhooks/transitions/one-time/purchase-completed.js
CHANGED
|
@@ -8,7 +8,12 @@ module.exports = async function ({ before, after, order, uid, userDoc, assistant
|
|
|
8
8
|
const brandName = assistant.Manager.config.brand?.name || '';
|
|
9
9
|
const productName = after.product?.name || '';
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
// Pre-compute discount values for the email template
|
|
12
|
+
const price = parseFloat(after.payment?.price || 0);
|
|
13
|
+
const discount = order.discount;
|
|
14
|
+
const hasPromoDiscount = discount?.valid === true && discount?.percent > 0;
|
|
15
|
+
|
|
16
|
+
assistant.log(`Transition [one-time/purchase-completed]: uid=${uid}, resourceId=${after.payment?.resourceId}, discount=${hasPromoDiscount ? discount.code : 'none'}`);
|
|
12
17
|
|
|
13
18
|
sendOrderEmail({
|
|
14
19
|
template: 'main/order/confirmation',
|
|
@@ -21,6 +26,14 @@ module.exports = async function ({ before, after, order, uid, userDoc, assistant
|
|
|
21
26
|
...order,
|
|
22
27
|
_computed: {
|
|
23
28
|
date: formatDate(new Date().toISOString()),
|
|
29
|
+
...(hasPromoDiscount && {
|
|
30
|
+
promoCode: discount.code,
|
|
31
|
+
promoPercent: discount.percent,
|
|
32
|
+
promoSavings: (price * discount.percent / 100).toFixed(2),
|
|
33
|
+
}),
|
|
34
|
+
totalToday: hasPromoDiscount
|
|
35
|
+
? (price - (price * discount.percent / 100)).toFixed(2)
|
|
36
|
+
: price.toFixed(2),
|
|
24
37
|
},
|
|
25
38
|
},
|
|
26
39
|
},
|
package/TODO-MARKETING.md
DELETED
|
@@ -1,56 +0,0 @@
|
|
|
1
|
-
1. Determine name via AI on signup
|
|
2
|
-
2. Add to sendgrid marketig cotacts
|
|
3
|
-
3. then, develop a way to SYNC them to the marketing contacts. we coould sync on payment changes (liek newly subscribed, cancelled, etc) so we can segment them??
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
When user sings up, use AI to generate first name, last name, company???
|
|
7
|
-
When user doc is updated, sync with sendgrid and beehiiv?? like name, premium status, etc
|
|
8
|
-
if admin is set to true from something else then we send an emergency critical email to alert us
|
|
9
|
-
|
|
10
|
-
need to confirm we hv hooks/events setup properly
|
|
11
|
-
handlerPath = `${Manager.cwd}/events/${handlerName}.js`;
|
|
12
|
-
liek bm_cronDaily, is it able to find the BEM path right? what about if we want to add our own per project?
|
|
13
|
-
|
|
14
|
-
implement BEM hooks (removed in muddleware semantic system)
|
|
15
|
-
|
|
16
|
-
https://firebase.google.com/docs/functions/2nd-gen-upgrade
|
|
17
|
-
|
|
18
|
-
------------
|
|
19
|
-
You are to extract the first name, last name, and company from the provided email.
|
|
20
|
-
|
|
21
|
-
If you can get the company from the email domain, include that as well but DO NOT set the company to generic email providers like gmail, yahoo, etc.
|
|
22
|
-
|
|
23
|
-
You may use a single initial if the email does not provide a full first name.
|
|
24
|
-
|
|
25
|
-
For example:
|
|
26
|
-
jonsnow123@gmail.com, jon.snow123@gmail.com
|
|
27
|
-
First Name: Jon
|
|
28
|
-
Last Name: Snow
|
|
29
|
-
Company:
|
|
30
|
-
|
|
31
|
-
jsnow123@gmail.com, j.snow123@gmail.com
|
|
32
|
-
First Name: J
|
|
33
|
-
Last Name: Snow
|
|
34
|
-
Company:
|
|
35
|
-
|
|
36
|
-
jon.snow@acme.com
|
|
37
|
-
First Name: Jon
|
|
38
|
-
Last Name: Snow
|
|
39
|
-
Company: Acme
|
|
40
|
-
|
|
41
|
-
jsnow@acme.com
|
|
42
|
-
First Name: J
|
|
43
|
-
Last Name: Snow
|
|
44
|
-
Company: Acme
|
|
45
|
-
|
|
46
|
-
jon123@gmail.com
|
|
47
|
-
First Name: Jon
|
|
48
|
-
Last Name:
|
|
49
|
-
Company:
|
|
50
|
-
|
|
51
|
-
every time we touch, cascada
|
|
52
|
-
just dance, lady gaga
|
|
53
|
-
over drake,
|
|
54
|
-
Time, hans zimmer
|
|
55
|
-
yellow, coldplay
|
|
56
|
-
yess bitch,
|
package/TODO-PAYMENT-v2.md
DELETED
|
@@ -1,74 +0,0 @@
|
|
|
1
|
-
TODO payments
|
|
2
|
-
|
|
3
|
-
would it be beneficial to... check the time on the event and the time in our datbase and skip if the time in oour database is nwer than the vent, indicatig that it is stale? or is this redundatn since we fetch the latest resource anyway?
|
|
4
|
-
|
|
5
|
-
next, we need to do certain things based on the CHANGE thats happening to the resource (subscription or one time) that is different that simply updating the user doc and the payments-subscriptions or payments-one-time collection. For example:
|
|
6
|
-
* if a new subscription is created, we send a welcome email and grant access to the product (but this cant happen when a user fixes their payment method from a failed payment, only when a new subscription is created)
|
|
7
|
-
* if a subscription is cancelled, we send a cancellation email
|
|
8
|
-
* if a subscription payment fails, we send a paymetn failed "please update your payment method" email
|
|
9
|
-
* if a subscription payment succeeds after previously failing, we send a "payment successful, your access has been restored" email
|
|
10
|
-
|
|
11
|
-
more endpoints to build
|
|
12
|
-
payments/cancel
|
|
13
|
-
* takes a subscrition id and requests to cancel at the end of the billing period (not immediately). this can only be done if the user has an non cancelled subscription.
|
|
14
|
-
* there should be an accompanying frontend form that asks some outboardig quetsions
|
|
15
|
-
* Why are you cancelling (checkboxes + textbox) with randomzed order of the checkboes
|
|
16
|
-
* after doing this, users should still be able to reactivate it
|
|
17
|
-
payments/manage
|
|
18
|
-
* fetches the customer portal link from the payment processor and redirects the user there
|
|
19
|
-
* acessible from the user's account page in biling setion
|
|
20
|
-
* only accessible if the user has a non cancelled subscription
|
|
21
|
-
|
|
22
|
-
Note: * for managing and cancelling, they should be under a sinlge button/dropdown called "manage subscription".
|
|
23
|
-
* it could have links to the 2 pages as items in the dropdown, or we could take them to a dedicated page (or expand an accordian) that has more information about managing it
|
|
24
|
-
* we need to make it hard to cancel, buried in some info, and make it more prominent to manage it, since we want to encourage users to manage their subscription rather than cancelling it.
|
|
25
|
-
|
|
26
|
-
payments/refund
|
|
27
|
-
* takes a subscription id and requests a refund to the payment processor
|
|
28
|
-
* we can only refund the most recent payment and we can only refund if the subscription is cancelled.
|
|
29
|
-
* we can only refund if the most recent payment in FULL was made less than 7 days ago, otherwise we can only refund a prorated amount based on how much time is left
|
|
30
|
-
* i want the subscription to be immediately revoked upon refund request
|
|
31
|
-
* generally, we dont modify the subscription DURING the http endpoint (such as payment intent, or cancel), rather we WAIT FOR THE WEBHOOOK. Can we do that here???
|
|
32
|
-
|
|
33
|
-
payments/reactivate
|
|
34
|
-
* takes a subscription id and reactivates a cancelled subscription. this can only be done if the subscription is still within its billing period, otherwise the user would have to create a new subscription.
|
|
35
|
-
payments/upgrade
|
|
36
|
-
* takes a subscription id and a new plan id and upgrades the user's subscription to the new plan. this can only be done if the user has an active subscription.
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
trial support:
|
|
40
|
-
when a peyment intent happens, we can only grant a trial if the user has never had a trial which involves checking the paymetns-subscriptions collection for the user to see if any exist. if any exist in any form, then we dont give a trial.
|
|
41
|
-
we also need a test for this
|
|
42
|
-
|
|
43
|
-
block multipl epayments
|
|
44
|
-
check if user has a non-cancelled sub during payment intent creation, if so, block the payment intent from being created. this will prevent multiple payments from being made at the same time and causing issues. we can check the payments-subscriptions collection for ALL usbcriptions belonging to the UID. we can use this for the trial check as well (recycle the results).
|
|
45
|
-
we also need a test for this
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
also, can you check and confirm if the usage.js sends back the users current usage in th headers? i think it does? maybe it our tests we can check to ensure that the user is probably having their usage set this way?
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
MANAGEMENT LINK
|
|
53
|
-
we need an endpoint that returns a management link for the user to manage their subscription. this will involve us looking up the users current subscription, then calling the appropriate method on the payment processor to get a management link. we can only return a management link if the user has an active subscription.
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
TODO
|
|
57
|
-
|
|
58
|
-
* authorizations ystem that tries to charge the card to see if its valid?
|
|
59
|
-
* bm_cronDaily task that doublechecks subscriptions??
|
|
60
|
-
* could check existing ones eveyr month to ensure they are still vlaud and not messed up from failed webhook processing or could check every day to ensure theres no users with multiple subscirptions active simultaneously?
|
|
61
|
-
* bm_cronDaily yto handle disputes?
|
|
62
|
-
* automatically provide evidence?
|
|
63
|
-
|
|
64
|
-
ATTRIBUTIONS!!!
|
|
65
|
-
// Filter attribution entries older than 30 days
|
|
66
|
-
const attribution = webManager.storage().get('attribution', {});
|
|
67
|
-
const maxAge = 30 * 24 * 60 * 60 * 1000; // 30 days in ms
|
|
68
|
-
const filtered = {};
|
|
69
|
-
|
|
70
|
-
for (const [key, entry] of Object.entries(attribution)) {
|
|
71
|
-
if (!entry?.timestamp) continue;
|
|
72
|
-
if ((Date.now() - new Date(entry.timestamp).getTime()) < maxAge) {
|
|
73
|
-
filtered[key] = entry;
|
|
74
|
-
}
|