#kbb_api

1 messages ¡ Page 1 of 1 (latest)

thick mangoBOT
#

👋 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/1225600363323850903

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

errant canyonBOT
torn jetty
#

Hi there, what's the checkout session ID?

gusty lava
#

i don't have 1 actually

#

let me get u one

#

hang on

torn jetty
gusty lava
#

i have this ID pi_3P20WkEktYhcBqrK0hRvlVea, does it help?

gusty lava
# torn jetty To clarify on "I would like to check who the payer is before capturing", you mea...

yes i think that is what i want

currently

  1. payer clicks buy
  2. redirect to stripe.com, payer provides funding details
  3. return to success_url, and funds already "transferred" to me

what i want

  1. payer clicks buy
  2. redirect to stripe.com, payer provides funding details
  3. return to success_url, but funds not "transferred" to me yet
  4. based on details now provided by stripe, i will decide whether to accept the funds from this payer
torn jetty
#

Ok, if I understand you correctly, you want to block certain transactions based on your criteria?

gusty lava
#

yup

#

but i wasn't able to with pi_3P20WkEktYhcBqrK0hRvlVea

torn jetty
gusty lava
#

waittt

#

i don't want to be passing these rules to stripe, it is going to complicate matters

torn jetty
#

Or maybe you can tell me what criteria you'll use to decide whether to pass or block a payment?

gusty lava
#

it varies from project to project, i just want to give my PHP library the ability to reject an incoming payment

#

sometimes, if there is heavy traffic trying to grab tickets

#

i also need this in order to see if the ticket is still available

#

before capturing the payment

#

if the ticket is no longer avilable, i need to reject the payment

gusty lava
torn jetty
#

Ok, here's my suggestion,

  • You should check your inventory before creating a checkout session.
  • Or refund the payment if your inventory can't satisfy the order
  • Or you can do manual capture (refer to the link I sent earlier), and only capture the payment if your inventory can satisfy the order.
gusty lava
#

i tried this and it did not work.. any idea?

        $params['payment_method_types'] = ['card'];
        $params['payment_intent_data'] = [
            'capture_method' => 'manual',
        ];

        $checkout_session = $this->getClient()
            ->checkout
            ->sessions
            ->create($params);

        return $checkout_session->url;
#

it says: You can not pass payment_intent_data in subscription mode.

torn jetty
#

That's expected. you can't use capture_method in a subscription mode subscription.

gusty lava
#

ok, what can i do?

#

i mean, subscription/payment etc, kind of means the same thing to me, i want to ensure i can fulfil the customer b4 capturing the funds

torn jetty
#

No, payments and subscriptions are two different things, and the scenario that you described earlier doesn't look like a subscription to me.

gusty lava
#

i only want to "ensure" at the last moment, and then capture the funds, otherwise payers can hog the inventory by taking their own sweet time to complete the stripe portion

#

have you checked pi_3P20WkEktYhcBqrK0hRvlVea? there is a payment of SGD233+ also, correct??

torn jetty
gusty lava
#

ok

#

could you please check pi_3P20WkEktYhcBqrK0hRvlVea?

torn jetty
#

What do you want me to check?

gusty lava
#

an amount of about SGD233+ was collected, which to me is a payment, not subscription

#

how do i manually capture that SGD233+?

torn jetty
#

A subscription will create invoices, and invoice will create payment_intent for collecting payments.

#

Are you asking if you can manually capture payments created by subscription invoices? No.

gusty lava
#

i see ok

#

and if i wan to block some payers from subscribing, is that possible?

torn jetty
#

You can implement your own logic to determine if a customer is eligible for subscription before creating subscription mode checkout session.

gusty lava
#

i meant after the checkout URL

#

because i rely on stripe to reliably establish the identity of the payer's email address

torn jetty
#

No, Stripe won't validate your customer's email address

gusty lava
#

not that per se

#

nevermind

#

despite the API being so big, it is so restrictive when it comes to subscriptions

#

let me rephrase my problem:

on stripe's checkout session, there is GPay and Pay with Link, so i rely on the payer choosing GPay as a means to validate who the payer really is

#

if this payer has misbehaved in the past, i would like to prevent them from subscribing

torn jetty
#

You mean you want to limit the subscriptions to customer who have Link or Google Pay accounts ?

gusty lava
torn jetty
#

Can you help me understand this part: "preventing subscription AFTER returning from stripe.com" ? Walk me through an example please.

gusty lava
#

ok, let's use GPay example

#
  1. user tells me they are good@b.com, so they click subscribe with stripe and gets redirected to stripe.com
  2. then they click GPay and returns to us, but stripe now tells me it is bad@b.com who has subscribed and paid SGD233+
  3. what I want is: after they click GPay and returns to us, i now know it is actually bad@b.com, so i can stop there and prevent bad@b.com from subscribing and having paid the SGD233+
  4. you can imagine my nightmare today of having to cancel the subscription, refund the SGD233+ and paying the transaction fees
#

my problem is #4 and i like a solution for it please

torn jetty
#

Then you implement your own email validation. As I said earlier, Stripe doesn't validate customer's email.

gusty lava
#

i can validate good@b.com but it doesn't change a thing

#

stripe will still tell me hey, bad@b.com just subscribed to you and paid SGD233+, good luck!

#

what i'm asking for is for stripe to ASK me: hey, bad@b.com wants to subscribe and pay SGD233+, can?

#

which i can reply: CANNOT or CAN

torn jetty
#

Here's how you can fix this problem

#
  1. Collect the email address from your customer, and validate it
  2. When you create a checkout session, specify the validated email address in the email_address field (https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer_email)
  3. Stripe chcekout will pre-fill this email and your customer won't be able to change it on the checkout page.
gusty lava
#

does this also work if payer picks GPay?

torn jetty
#

Yes

gusty lava
#

are you certain GPay will return a user specified email address instead of the one that was used to create the GPay account?

torn jetty
#

Please try it out, feel free to reach out again with relevant request IDs if you have further questions.

gusty lava
#

i want to stop the session AFTER stripe returns to my website, but instead, you turned it into a email validation process which still doesn't allow me to stop the session

#

so maybe let me rephrase the problem once again:

can i STOP/TERMINATE completion of the session AFTER stripe returns to my website? Or is there no way this can be achieved?

torn jetty
#

There's no need to shout

gusty lava
#

shouting is all caps, i'm merely highlighting the keywords that i think you missed

torn jetty
#

I'm trying my best to help you here, and I do hope I can have some respect. I really hope it can be a misunderstanding in a way that you choose to communicate with people.

The session is already complete when your customer returns from Stripe checkout page to your website.

#

So to answer your question, there's no way to stop/terminate completions of the checkout session after your customer returns to your website/

#

Is there anything else I can help with?

gusty lava
#

nothing else thanks, but you do seem very sensitive to caps, which was in no way shouting as i explained.