scene1607_api

[molten oak]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1265810407520600132

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[vale shoal]

Hi there

You mentioned Checkout and linked to the Create a Subscription endpoint. You wouldn't use both as there's no need to call the Create a Subscription endpoint directly when using Checkout; Checkout will create the Subscription for you

express account users that our application previously signed up for
Can you share more context here? I don't I understand

[dawn dew]

Hi sure

I'm simply using the accounts.create to create express accounts for the users of our application when they signup

so something like this:

const stripeInstance = new stripe(key);

    const account = await stripeInstance.accounts.create({
        email,
        type: 'express',
        capabilities: {
            card_payments: {
                requested: true,
            },
            transfers: {
                requested: true,
            },
        }
    });

    return account.id;

this is returning the account id, which is working pretty well

each user has an express account

so I want to allow these users to pay for a subscription plan, my idea is that Stripe identify the users by their express account id

and set a monthly charge for the user

something like that

I hope this makes sense?

[vale shoal]

Thanks for the details

This kind of makes sense. Since you're working with connected accounts, I assume these Express users also have customers of their own?

[dawn dew]

let me see how to explain it, recently built an onboarding application for a client using express accounts, so yes those express customers have their own customers.

Now in this case I'm just making a quote for another client where previously I built a basic stripe checkout solution so they can sell products, in fact, wine but, is not wine the real thing instead is wine investment so customers of our client, invest in fine wine, as it age becomes more expensive. The point is our client needs to monthly charge the customers for storing and keeping safe the wine.

My plan was to create express accounts for each customer and then built on the backend a solution to create subscriptions

so I do have experience building applications with Stripe, but in this case just thinking of a simple solution to integrate with the existing stripe module that is in this application, also my client have a very poor budget so I can not build a super complex solution for them

[vale shoal]

create express accounts for each customer and then built on the backend a solution to create subscriptions
Is this because these customers (investors in wine) also need to charge their own customers?

[dawn dew]

I need something simple that can do the job so I can quote it and see if my client is willing to pay for it (greedy to be honest)

no, they don't need to charge their own customers, sorry for the confusion

[vale shoal]

I'm asking just to be sure we're on the same page. I understand there are two parties involved currently: The client who is selling wine investment and the investors. Is that correct?

[dawn dew]

customers only need to pay my client for storage and keeping safe the wine that they invest on

[vale shoal]

Okay, in that case you don't need Express accounts or to use Connect at all

[dawn dew]

ok perfect, one more thing I learned today so express accounts are only for onboarding applications?

[vale shoal]

Express (and other Connect accounts) are only for multiparty payments

Think of a ride share service for example. The ride share platform needs a way to charge the rider and pay the driver. In this case, the driver has a Connected account and the rider is just an end customer

[dawn dew]

I have the concept of express accounts because I just completed an application where the customers of my client charge users by a live chat for services

yes, no worries all clear, thanks

[vale shoal]

Right, that makes sense. You have your client, the client customers, and the customers of their customers

[dawn dew]

correct

but in this case we don't need this type of customer model, we only need this:
customers only need to pay my client for storage and keeping safe the wine that they invest on

[vale shoal]

You can use Checkout to subscribe customers to a recurring price

No need to call the Subscriptions API directly

[dawn dew]

sounds good

so I guess I just have to add more parameters to the current stripe checkout on the backend?

[vale shoal]

I recommend starting here: https://docs.stripe.com/billing/subscriptions/build-subscriptions

Then, once your Subscription is created, you can use the Dashboard to simulate moving to the next billing cycle just to see it in action: https://docs.stripe.com/billing/testing/test-clocks/simulate-subscriptions

[dawn dew]

This seems clear, https://docs.stripe.com/billing/subscriptions/build-subscriptions
Basically is adding mode:"subscription"

I already have a stripe checkout component fully working on the application

[onyx mason]

Hi @dawn dew I'm taking over this thread. Let me know if you have any follow-up questions

[dawn dew]

it seems to me I could simply add this mode:subscription and make it work fine

Hi @onyx mason thanks. I just feel something doesn't "click" yet I mean do I have to create a subscription plan some how?

[onyx mason]

You mean this? https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=android#create-pricing-model

[dawn dew]

let me share my code that is working well on the framework that I'm using this is NodeJS without express framework let me share it

export async function createPayment(productId, quantity){

// Layer of security to prevent an attacker from injecting in the system their own values
if(quantityChecker(productId, quantity) === "unauthorized")
    return 

// Fees calculated by the application
let productInfo;
try{
    productInfo = await feesAndCosts(productId, quantity);
}
catch(err){
    console.log("Backend Paymanger feesAndCost call error", err);
}
console.log("info", productInfo);
// Stripe
try{
    const apiKey = await wixSecretsBackend.getSecret("secretTestKey");
    const stripeInstance = new stripe(apiKey);

    const formatedStrPrice = `${productInfo[0].nativeSymbol}${productInfo[2].finalCost} ${productInfo[0].currencyCode}`
    const product = await stripeInstance.products.create({
        name: productInfo[3].name,
        description: `Quantity: ${quantity}, Total cost: ${formatedStrPrice}`
    });

    const price = await stripeInstance.prices.create({
        unit_amount: productInfo[2].finalCostInCents,
        currency: productInfo[0].currencyCode.toLowerCase(),
        product: product.id
    });

// NOTE: **** CHANGE URLS TO PRODUCTION LEVEL DOMAIN ****
    const session = await stripeInstance.checkout.sessions.create({
        line_items: [
            {
                price: price.id,
                quantity: 1
            }
        ],
        mode: "payment",
        success_url: "https://tradinggrapes.com/successful-payment",
        cancel_url: "https://tradinggrapes.com/fees"
    });
    console.log("Stripe session", session);
    await insertPotentialPurchase(productInfo, session.id);
    return session.url;
}
catch(err){
    console.log("Backend error payManager ", err);
}

}

hm better I share a picture

this is a mess without code writter

[onyx mason]

It's OK, I can read the code

[dawn dew]

alright

so the return session.url is the url for stripe checkout this is all working well

[onyx mason]

So I saw you created a product, then a price, and pass the price ID to the checkout session creation API.

If you want to use subscription mode checkout session, one of the price that you specified in line_items must have recurring hash

https://docs.stripe.com/api/prices/create#create_price-recurring

[dawn dew]

I just want to set a subscription plan hopefully as simple as possible because my client is greedy and is not willing to pay that much for my time

sounds good, let me check this info

fantastic

so I can create a recurring price

and keep the same flow that I already have, right?

should I simply add here:

the recurrent parameter? in the line_items?

line_items: [
{
price: price.id,
quantity: 1,
recurring: {
interval: 'month',
}
}
],

something like this?

[onyx mason]

No, you should set recurring in the price creation request.

https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-line_items-price_data or specify it in price_data if you want to create inline price.

[dawn dew]

ok good, so here:
const price = await stripeInstance.prices.create({
unit_amount: productInfo[2].finalCostInCents,
currency: productInfo[0].currencyCode.toLowerCase(),
product: product.id,
recurring: {
interval: 'month',
}
});

right when I create the price object

[onyx mason]

Yes, it looks good to me.

[dawn dew]

good, now when the user pay on the stripe checkout I have a webhook, that is working well

I built an API endpoint and its connected to Stripe

so when the user pay for something successfully Stripe sends data to our API endpoint

this is working well

with the new recurring mode is this going to be affected?

does it receive the same type of data, or different (from stripe)?

[onyx mason]

https://docs.stripe.com/billing/subscriptions/webhooks#events this page tells you the list of webhook events that you should listen to for your subscription integration

[dawn dew]

Fantastic, thanks.
I guess the best, is to let this existing module as it is and build the subscription module without trying to reuse any function

that can actually affect the current application

so I'll quote a new module with recurrent payments and a new API endpoint for the webhook

and apart of that, managing data for the user locally in the application database

oh boy, this isn't cheap but this client is greedy I don't think this can be done with small budget anyway, I think everything is clear

this is the simplest solution available right?

[onyx mason]

Yes, the easiest way to build a subscription integration is through Stripe checkout. But handle webhook events from recurring payments is more complicated than an one-off payment.

[dawn dew]

do you mean because monthly Stripe has to send back data for the user, and the application will have to take the data, process it, track the subscription and make decisions where application services continue available or not and stuff like that?

The endpoint will be always open so Stripe can send data any time, I guess the user has to be flagged on the local database as a user that has paid or not and based on that build following logic

[onyx mason]

Yes, so basically your endpoint need to listen to these events and decide whether to allow the customer continue using the service.

[dawn dew]

yes

that's why I thought is not a cheap solution and this client is a headache because is greedy

but I appreciate your help

this is enough information for this project

[onyx mason]

https://docs.stripe.com/billing/subscriptions/overview I'd also recommend this doc, it gives you a comprehensive overview about subscription.

[dawn dew]

thanks for the information. When a user is going to be charged how Stripe deliver this request to the user?

is it sent via email to the user?

[onyx mason]

It depends on the collection_method https://docs.stripe.com/api/subscriptions/object#subscription_object-collection_method. Stripe will send invoice emails if the collection_method is send_invoice. Otherwise Stripe will automatically charge the customer with the default_payment_method, and send receipt email (if receipt email is enabled in Dashboard)

[dawn dew]

is this thread possible to be accessed later? to read this conversation in case I forget something?

[onyx mason]

The thread is always available, but it will be locked and closed after a while.