#wurkzen

1 messages · Page 1 of 1 (latest)

twin tundraBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

  • Wurkzen, 18 hours ago, 17 messages
clever torrent
#

Hi yes what's your question?

late lake
#

Yes, we are syncing our products and services to stripe to avoid creating multiple products in stripe for the same products and services in our system

#

Because if we didnt sync, everytime we create a custom checkout it would create the product in stripe every single time, so after 500 orders you would have 500 copies of the same product in stripe

#

Is this a good practice? The issue we are having is that if we increase the price on a product or service that has a custom checkout already it is giving us an error

#

So what im asking I think is

#

one second, let me check something first

twin tundraBOT
late lake
#

So what im wondering

#

If we have an invoice in our system and we update the price on the service, should we update the price of the service in stripe as well?

clever torrent
#

Yeah that's up to you entirely. However, if you have open stripe invoices with the old price, you'll need to void them first so the customer doesn't pay will old price

#

Unless you're fine with them paying the old price since invoice was created prior to the price change

late lake
#

Ahhhh I see

#

So if we change the price we should always VOID the previous invoice/checkout and create a whole new one

clever torrent
#

If you want them to pay new price

late lake
#

well, that was easy 😄

clever torrent
#

Up to you

late lake
#

Sure, of course, or maybe we just make it so that every single checkout is a new payment intent

#

and we create a new checkout every time

clever torrent
#

Yep

#

Up to you

late lake
#

One more question for you

clever torrent
#

But both are valid solutions

#

Sure what is it

late lake
#

As part of our platform we are onboarding our customers stripe connected accounts, they are not express accounts but regula accounts

#

During the onboarding process

This is what happens:

#
  1. The customer is redirected to stripe where they enter their email and password and the account is created, we receive the webhook and appyl the account_id to our client payment processor table
  2. The customer fills out all of the information required by stripe and is redirected back to Wurkzen.
  3. We receive the accountupdate webhook but the account is not verified so we dont mark it as fully onboarded, becuase of this, we redirect the customer back to stripe to provide missing information
  4. The customer provides the missing information, usually ID, social security numbers, etc and is redirected back to Wurkzen.
  5. We received the account update webhook but the account is STILL not marked as verified. So we redirect the mto stripe again when they try to make a payment.
  6. This time, stripe asks for MORE information and then finally we received the webhook with account verified
  7. Now we let the customers process payments
#

Why is this process so complicated? It seems that stripe should ask for all of the information upfront instead of making us redirect the customer so many times.

#

I understand that there may be some backend processes in stripe that prevent the account from vbeing verified all in one shot so what do you recommend. I imagine that there is a webhook that comes in if an account is going to be limited or they will be unable to make payments at which point we can set a flag in our DB that will show the modal to the user that they have to go to stripe to provide additional information

#

If so I imagine its in the account updated webhook but what is the field we should be lookign for? at this point maybe we can set a payments_restricted = 1 flag which will force the redirect to stripe.

The reason why I am considering this now is because maybe stripe may not be able to verify the account in just one day so I dont want to stop customers from being able to process payments unles we get a webhook from stripe informing us that you need more info or the account will be restricted at which point we set a flag to show the modal and redirect to you

native helm
late lake
#

I see

#

I think we can do this but would webhook event could I use to force my users to start going to stripe when processing payments?

#

Right now its not good because im forcing them to go through until we receive the "verified" webhook which could take days

#

So I think we should look for another item in the accoutn update webhook to set a flag in our system to force them to go to stripe when processing a payment

native helm
#

I'm not sure what you mean by "force them to go to stripe when processing a payment" can you clarify a but on what specifically that looks like?

#

The webhook can tell you when their account is ready to accept payments, but it sounds like you are already checking for that

late lake
#

Basically

We have a client_payment_processor table

Here we have the payment_processor_id
the account_id and an account_onboarded 0/1 value.

I need to verify to see what we are checking to set account_onboarded = 1

#

I found it, this is what we are looking for:

    if ($account->charges_enabled) {
        $client_payment_processor->account_onboarded = true;
        $client_payment_processor->save();
    }
native helm
#

Yep, that is the property if you are using our direct charges flow

late lake
#

So basically we are not letting them process any payments at all until account_onboarding = true.

native helm
#

For destination charges or separate charges and transfers you would want to look to see if the transfers capability is enabled

late lake
#

But until we received this charges_enabled webhook they will not be able to process any credit card transactions for their customers, it will always tell them their STripe setup is incomplete on our end

#

let me show you what it looks like

#

Anytime they go to charge a customer credit card, and they click charge it will show them this

native helm
#

I do not recognize that page. Is it a page on a website with a url that includes stripe.com?

#

a lot of other websites have prebuilt integrations with us, but we can't speak to how their integrations work with us. If that page is on another site, I'd reccommend talking to them about how best to get this working on their site

late lake
#

Understood... but last question

#

once I received charges_enabled does that mean this account is ready to take card payments from their customers?

native helm
#

For specific setups that is what that property means, from what you have described, it does sound like that is the case in your situation, but I don't know enough to say for sure

#

Like I mentioned, this would be dependent on your connect charge type that you are using, but it sounds like that other site may be handling that part for you?

late lake
#

No this is built into our platform

#

We did a direct integration

#

I'm the CTO so I'm asking at what point can I allow a business to charge their customers. We are not even using direct charges right now

native helm
#

Can you send me the ID of one of the connected accounts that you have created? I feel like we have been talking past each other a bit. Looking at one of your actual setups will help me understand more about what you are trying to do

late lake
#

Sure

#

I have one more unrelated question

#

How does the buy now pay later option work? Is that an option that is used in the custom checkout?

#

Is it a simple value we can send when creating the custom checkout to offer that? or is it more involved?

native helm
#

That can mean a couple of things, mostly our BNPL support comes from a number of BNPL payment methods, so there isn't a single BNPL switch to turn on and off, it is more a matter of which of the payment methods you designate should show up https://docs.stripe.com/payments/buy-now-pay-later

late lake
#

Where do we designate these? Does it have to be done for each connected account? Can it be done via API?

native helm
#

Unfortunately those settings are not settable via the API as far as I am aware

late lake
#

"capabilities": {
"acss_debit_payments": "active",
"affirm_payments": "active",
"afterpay_clearpay_payments": "active",
"bancontact_payments": "active",
"card_payments": "active",
"cartes_bancaires_payments": "pending",
"cashapp_payments": "active",
"eps_payments": "active",
"giropay_payments": "pending",
"ideal_payments": "active",
"klarna_payments": "active",
"link_payments": "active",
"p24_payments": "active",
"sepa_debit_payments": "active",
"transfers": "active",
"us_bank_account_ach_payments": "active"
},

#

This is what I received from my stripe connected account

#

I answered my previous questions to you by running throgh the process and looking at the webhooks

#

so now eveyrthing is active, but i also noticed the affirm and klarna

#

looks like its activated by default

#

i went into the dashboard as well o nthis account and they are all active

#

So when customers go to a custom checkout for this account, will stripe automatically display the affirm/klarna options?

native helm
#

You will also want Affirm and Klarna set to active on the settings page that I linked. Those capabilities represent whether the account can take affirm and klarna payments at all, but whether they show up automatically in Checkout is a separate behavior

twin tundraBOT
late lake
#

yes that is correct

#

So im assuming the behavior to show it is based on Stripes algorithims

native helm
#

Exactly, on that BNPL doc that I linked to, we link to pages for each specific payment method and those pages specify currency restrictions, amount restrictions and show on. We show the payment method as an option if you have it enabled in your settings and if the payment is eligible given its amount/currency/etc

#

You can also specify your desired payment methods via code, but they are subject to those same restrictions

late lake
#

cool

#

thanks Pompey!