#Pickle_Rick-connect-direct

1 messages · Page 1 of 1 (latest)

foggy mango
#

Hello! When you say you're having trouble "connecting customers to my platform", do you mean connecting your connect accounts, or having customers pay?

worthy tide
#

Hi there,

#

thank you for your response

#

Yes, so I am having trouble connecting my connect accounts.

#

I offer an online ordering system that is embedded in restaurants (my customers) websites. I want to set it up as Direct Charges so that my customers are responsible for Stripe Fees, refunds and chargebacks etc.

foggy mango
#

Gotcha - so I assume you're working with standard accounts (which is the recommendation for direct charges). What specific issures are you running into?

worthy tide
#

Thanks, so I tried connecting a Standard account, however I got directed to Connect Setttings to allow Oauth for Standard Accounts.
What do I need to do from here?

#

Also where are the URI redirects suppose to take us? What URI do I put in there?

foggy mango
#

Basically, the redirect_uri should be one of your own pages that you want to direct your user towards after they're done connecting.

worthy tide
#

Ok just read through that document and I'm lost as to what I need to do now. I was under the impression we would just need to send our customer a link from our Stripe to authorise the connect?
We don't want every one of our customers to come to our website to sign up and connect. We just need to tell our Stripe account to which Stripe account the money will be sent to and manage that through the Stripe platform. Is this possible? Thanks for your patience with me

foggy mango
#

Every customer/user you have that accepts payment through Stripe would need to sign up and be connected to your platform account - or does customer in this case mean someone that is paying you?

worthy tide
#

So our customer has a Stripe account, we are just trying to connect them to our platform

#

This is what we are looking for

#

So that they can receive payments from users on their site ordering food

foggy mango
#

Yes, you can send your customers a link to start the connection process, but it isn't as simple as just sending them the link and forgetting about it. The reason why the redirect to your own site is necessary is that you need to actually do some additional steps complete the connection (see https://stripe.com/docs/connect/oauth-standard-accounts#token-request).

#

It walks through how to do all this through the dashboard (which requires not code). You can create connect accounts through the dashboard and a one-time link will be generated that you can send to your user

worthy tide
#

Great thank you, this is exactly what I'm looking for. We want to keep this all in the dashboard. So once my customer is connected what do I do from there?

#

I've sent the link, and once they have filled this out, will their account automatically appear under our connected accounts?

foggy mango
#

Yup!

worthy tide
#

Groovy thanks, so can we set up the direct charge payments on the dashboard or do we need to make code changes?

foggy mango
#

I need to head out, but @gaunt wedge is hopping in to help!

worthy tide
gaunt wedge
#

@worthy tide stepping in on behalf of karbi! we can't create direct charge payments via the Dashboard so you would need to make the necessary code changes (if any).

worthy tide
#

Hi there, ok can you please direct me to the sample code that can be used to set up direct charge

gaunt wedge
worthy tide
#

Ok thanks, so once the customer is connected to our platform will their connected account ID be displayed?

gaunt wedge
worthy tide
#

Brilliant thank you Alex. If we have multiple Stripe accounts connected how will we handle this? That page you sent has a Javascript example of only having just one.

gaunt wedge
#

you would inpput the connected account id in the Stripe Account parameter

#

that's how you differentiate between making a direct charge on connected account A versus making a direct charge on connected account B

#

was that what you were asking?

worthy tide
#

Great Thanks I understand the above. The confusion is here. For each connected account do we need to create and entry like this? Thanks

gaunt wedge
#

it depends - so the reason why that section of the doc is saying that is because for a direct charge, the charge occurs on the connected account. Since the charge occurs on the connected account, the payment method would need to exist on the connected account as well.

That section is essentially trying to say that, you would need to initialize stripe that way, so that when you create the card details, the payment method would be created on the connected account (not the platform) - https://stripe.com/docs/payments/payment-methods/connect#create-payment-method

But! there is another method - you can collect the card details on the platform and the clone the payment method to the connected account - https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods

worthy tide
#

Right thanks ill check out this cloning method.
However, in the javascript setup, how would you include 3 or more connected accounts to which payment may be made?

gaunt wedge
#

hmmm, so you want to split a payment between 3 connected accounts?

worthy tide
#

No we are just wanting to have multiple accounts links to our platform receiving direct charges. Or is Direct charges only for one account?

gaunt wedge
#

direct charges can be used for different connected accounts. It's not limited to one connected account only. You would input the Stripe account id in the Stripe account parameter for whichever account you want the charge to occur on

gaunt wedge
#

👋

worthy tide
#

hey thank you

#

so, How do I resolve a 401 error - the attempt appears in my Stripe account but failed

#

I see there is a payment method missing somehow - never showed that before

gaunt wedge
#

could you share the request id?

worthy tide
#

it says the payment method was not set - this was ok in test.

gaunt wedge
#

hmmm, i'm not able to find the request log in your account, can you paste the full error?

worthy tide
#

sorry mate my devs computer just froze

#

is is restarting and will get back to you

#

of course all these issues happen on go live day haha

gaunt wedge
#

no worries

worthy tide
#

ok

#

here we go

gaunt wedge
#

generally 401 errors are when the wrong API key is being used, trying to see if i can find further information on the request you made

worthy tide
#

{
"id": "pi_3JcLeoH3FnYor84o114JHH2c",
"object": "payment_intent",
"last_payment_error": null,
"livemode": true,
"next_action": null,
"status": "requires_payment_method",
"amount": 100,
"amount_capturable": 0,
"amount_received": 0,
"application": null,
"application_fee_amount": null,
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "automatic",
"charges": {
"object": "list",
"data": [
],
"has_more": false,
"total_count": 0,
"url": "/v1/charges?payment_intent=pi_3JcLeoH3FnYor84o114JHH2c"
},
"client_secret": "pi_3JcLeoH3FnYor84o114JHH2c_secret_TEVZ5AmWRG8K6IdrO17G2RAus",
"confirmation_method": "automatic",
"created": 1632279482,
"currency": "nzd",
"customer": null,
"description": null,
"invoice": null,
"metadata": {
"integration_check": "accept_a_payment"
},
"on_behalf_of": null,
"payment_method": null,
"payment_method_options": {
"card": {
"installments": null,
"network": null,
"request_three_d_secure": "automatic"
}
},
"payment_method_types": [
"card"
],
"receipt_email": null,
"review": null,
"setup_future_usage": null,
"shipping": null,
"source": null,
"statement_descriptor": null,
"statement_descriptor_suffix": null,
"transfer_data": null,
"transfer_group": null
}

#

this is the full error

worthy tide
#

in Stripe = says payment method is not provided???

gaunt wedge
#

yeah, there wasn't a payment method provided. You need to have a payment method to charge

worthy tide
gaunt wedge
#

lets take a step back, how did you collect the customer's card details in test?

worthy tide
#

Sorry sent the message twice, updated

#

ok ill send you a screen shot now

#

using that control - elements

gaunt wedge
#

alright, so after you collect the card details, you would use the ConfirmCardPayment with the PaymentIntent's client secret to confirm the PaymentIntent

#

but when you attempted to confirm the card payment, i assume you ran into that 401 error

#

which is why the PaymentIntent is still in the requires payment method state

worthy tide
#

right just checked everything:

  • key is correct.
  • private key on our server is also correct.
    I am putting the connected account id in the request options as described in the code sample
gaunt wedge
#

could you elaborate a bit more on I am putting the connected account id in the request options as described in the code sample?

#

pi_3JcLeoH3FnYor84o114JHH2c is neither a direct charge, nor a destination charge, so i'm a bit baffled as to where the connected account is coming into play here

gaunt wedge
#

umm, okay, i think i'm probably not understanding something

#

you are using both Elements and Checkout?

worthy tide
#

we create a session on the server to process the order after successful payment - is that not the session id?

worthy tide
gaunt wedge
#

elements and checkout are both used to collect card details for payment. There really isn't a need to do both.

#

so for example, if you already confirmCardPayment

#

there is no need to create another Checkout Session to further process that payment

worthy tide
#

we post the order to the server and obtain a session id from there. Then the client processes the payment within the client and after successful payment, the server is updated.

gaunt wedge
#

give me a second to try and wrap my mind around what you're doing - it looks to me like you're doing both Checkout and Elements, but based off your explanation, you're not

#

am i right to say :

  1. you're creating a session,
  2. and then getting the PaymentIntent client secret from the session,
  3. and using that client secret in confirmCardPayment?
worthy tide
gaunt wedge
#

this is a really unusual integration method

worthy tide
#

examples show that the server needs to produce the order and then pass that to the client. as this worked fine in with test accounts, we had no reason to suspect that it would not work in the live environment

#

we needed to have control in the client of the payment processing as the component runs inside an iframe already

#

and directing back to the instance is not possible

gaunt wedge
#

i'll be right back, give me a while to look into the 401 error again

worthy tide
#

Ok, thank you very Alex. Really appreciate it

gaunt wedge
#

sorry @worthy tide i need to step out for a bit but i've explained to @storm quest about the issue you're facing and he'll help you out here once he's caught up on the conversation here

storm quest
#

@worthy tide I am taking over for @gaunt wedge here.

worthy tide
#

Hey mate thanks

#

Hi WSW, switching back to test environment just works like before - no code changes

storm quest
#

as probably mentioned by @gaunt wedge , your integration path is not a recommended integration

#

instead of creating Checkout Session and get the payment_intent, you should really create payment_intent directly in your server side.

worthy tide
#

and pass that intent to the client?

storm quest
#

correct, pass the payment_intent.client_secret to the frontend

worthy tide
#

the payment has to be taken on the client

storm quest
#

right, that is what payment_intent.client_secret is for

spring patrol
#

@worthy tide do you have an example where it happens just out of curiosity? You shared a pi_123 earlier but this one is completely unrelated to Checkout. If you could give an example Checkout Session id cs_live_123 it'd help us narrow it down.

worthy tide
worthy tide
storm quest
#

as I mentioned, it works but it is not a recommended way to do the integration. Checkout session is creating payment_intent under the hood to drive the payment and we don't expect you to deal with the payment_intent directly.
If you just need a payment to go through, there is no need to use checkout session, creating a payment_intent is sufficient.

worthy tide
#

client secret

spring patrol
#

@worthy tide I worry you're maybe not understanding the integration you are debugging. This PaymentIntent was not created via Checkout at all. Your code in .NET explicitly went and created the PaymentIntent via the https://stripe.com/docs/api/payment_intents/create API as expected. Also it is not a direct charge flow, it's just a PI on your own Stripe account

#

Like here there is zero Connect impact, your code just used your own API key with no StripeAccount option and created the PI on your own account

spring patrol
#

PI = PaymentIntent

#

my colleagues asked clearly earlier if you were creating a Checkout Session and using that Session's PaymentIntent's client_secret and you said yes, and shared code that creates a Session via https://stripe.com/docs/api/checkout/sessions/create (completely different/separate product) but I think you're likely mixing things up. That PaymentIntent at least has nothing to do with Connect, direct charges or Checkout

#

Have you been able to get a 401 for that new PaymentIntent?

#

Do you also have a URL I can look at quickly?

worthy tide
spring patrol
#

Okay so something is weird, I don't see any request internally with that PaymentIntent id anywhere (Except the creation)

#

I mean your URL, wherever you are experiencing the 401

#

I'm struggling to follow the report because what you said your code does is definitely not what is happening here

spring patrol
#

Thanks! It's not working it seems to be loading indefinitely

storm quest
#

same here

spring patrol
#

Okay I think I have a clue

#

401 == bad API key

#

looking at logs with that domain you seem to be passing an invalid API key

spring patrol
#

instead of passing the API key pk_live_123 you pass pk_live_123bpk_test_123

#

that works but I can't choose a time so I can't move to the next step

#

But yeah based on what I see right now in our logs with that domain, you have a bug in your config or something and you incorrectly concatenated 2 API keys by mistake

#

can you double check that?

worthy tide
#

give me a moment 🙂

spring patrol
#

it'd explain why we have no logs, we have tools that reject all requests "at the edge" when the API key is invalid

#

and so that API key is just broken and we never log anything we just 401

worthy tide
#

we're rebuilding and will test again

#

ok, payment works now - we will attempt to reconnect to the connected account for another test

#

@spring patrol payments are now working direct to our account. we have a connected account configured but the payment is not going to that account - how do we resolve that. Both the server and the client has the connected account id configured

spring patrol
#

@worthy tide I'm not sure what that could mean. Unfortunately most of the information you gave in this thread was incorrect earlier, since checkout seems never used, so I'm not sure how to help unblock without actionable information
But to me, right now, you are just not doing the flow documented at https://stripe.com/docs/connect/direct-charges at all and just create objects on your account which is wrong
You need to find the code you use the create the PaymentIntent and understand whether you're passing the account id or not, both server-side and client-side

#

I have to disconnect for the day but I do think you want to add logs to your code first and better understand how it works in Test mode and then understand why it doesn't create the PaymentIntent on the connected in Live mode (assuming it works in Test mode which it might not). Overall you really aren't passing the Stripe-Account header in your code
@storm quest on my team can help if you have more specific questions

worthy tide
storm quest
worthy tide
storm quest
#

can you copy paste your code here? you will need to set the StripeAccount header.

#

and also just to confirm, are you changing your production code live and test it? Which payment_intent went directly to your account?

worthy tide
#

intent secret: pi_3JcOGDH3FnYor84o1IaYo6AX_secret_fpqfMMAgtU12gX5Q2ceY0RrtY

#

client code: this.stripePromise = loadStripe(environment.STRIPE_KEY, {stripeAccount: '{{acct_1G9KlQDV2WR4Y5rU}}'});

storm quest
#

yeah, pi_3JcOGDH3FnYor84o1IaYo6AX was create in your server side, what is your server side .net code?

worthy tide
#

var intentService = new PaymentIntentService();
var createOptions = new PaymentIntentCreateOptions
{
PaymentMethodTypes = new List<string>
{
"card"
},
Amount = Convert.ToInt64(payment.Amount),
Currency = "nzd"
};

        var requestOptions = new RequestOptions();
        requestOptions.StripeAccount = "{{acct_1G9KlQDV2WR4Y5rU}}";
        var intent = intentService.Create(createOptions, requestOptions);
        return new OkObjectResult(intent.ClientSecret);
#

on the servver

storm quest
#

requestOptions.StripeAccount = "{{acct_1G9KlQDV2WR4Y5rU}}"; should be requestOptions.StripeAccount = "acct_1G9KlQDV2WR4Y5rU";

#

are you using your live secret key for testing?

worthy tide
#

I had that code before I added the {{ and }} because it didn't work, will try again without

#

and yes using the live key for testing

storm quest
#

any reason why you would use live key to do the test? I would recommend you to use test keys so that you don't have to pay real money for testing

worthy tide
#

only one dollar

#

happy to pay to get this working lol

storm quest
#

I think the money is one thing, another thing is that you might be risking

  1. your account being flagged as card tester or casher
  2. your bank might block your card to prevent it from normal usage
#

the test mode will work exactly the same as live mode, there is no reason to test in live mode

worthy tide
#

last payment intent secret:

#

pi_3JcOZsH3FnYor84o1bWLgboC_secret_GsUHHPD1v5PvOtkEYgNeXdon8

#

Brackets removed, still being paid to our account not connected account

storm quest
#
requestOptions.StripeAccount = "{{acct_1G9KlQDV2WR4Y5rU}}";
        var intent = intentService.Create(createOptions, requestOptions); 

can you add some log after this line and print it out and share the content of intent here?

#

How are you testing the integration? are you testing it locally on your .net server?

worthy tide
#

no I am not doing this locally, I am running this in Azure

storm quest
#

yup, do you mind adding log in your .net server and print out the requestOptions and intent making sure they are passing the right parameter?

worthy tide
#

I'm not sure how to do that. Any suggestions?

storm quest
#

are you using asp.net mvc or something like that?

worthy tide
storm quest
worthy tide
# storm quest > requestOptions.StripeAccount = "{{acct_1G9KlQDV2WR4Y5rU}}"; > ...

{"id":"pi_3JcPPlDV2WR4Y5rU1ErJDvsS","object":"payment_intent","amount":100,"amount_capturable":0,"amount_received":0,"application":"ca_KGqFIbk0OAqaFaSHSIzbGitYnHXamUao","application_fee_amount":null,"canceled_at":null,"cancellation_reason":null,"capture_method":"automatic","charges":{"object":"list","data":[],"has_more":false,"url":"/v1/charges?payment_intent=pi_3JcPPlDV2WR4Y5rU1ErJDvsS"},"client_secret":"pi_3JcPPlDV2WR4Y5rU1ErJDvsS_secret_9Wa2EjwTAowbX0LmbpJM7TkEa","confirmation_method":"automatic","created":1632293925,"currency":"nzd","customer":null,"description":null,"invoice":null,"last_payment_error":null,"livemode":false,"metadata":{"integration_check":"accept_a_payment"},"next_action":null,"on_behalf_of":null,"payment_method":null,"payment_method_options":{"acss_debit":null,"afterpay_clearpay":null,"alipay":null,"bancontact":null,"boleto":null,"card":{"installments":null,"network":null,"request_three_d_secure":"automatic"},"card_present":null,"ideal":null,"oxxo":null,"p24":null,"sepa_debit":null,"sofort":null,"wechat_pay":null},"payment_method_types":["card"],"receipt_email":null,"review":null,"setup_future_usage":null,"shipping":null,"source":null,"statement_descriptor":null,"statement_descriptor_suffix":null,"status":"requires_payment_method","transfer_data":null,"transfer_group":null}

#

Here's the payment intent. Formatted in Json

storm quest
#

yup, now it looks correct and the payment_intent was created to the connected account acct_1G9KlQDV2WR4Y5rU

#

you should pass "pi_3JcPPlDV2WR4Y5rU1ErJDvsS_secret_9Wa2EjwTAowbX0LmbpJM7TkEa", to the frontend

worthy tide
#

I just got a 404 error again

storm quest
#

in your frontend right?

#

loadStripe(environment.STRIPE_KEY, {stripeAccount: '{{acct_1G9KlQDV2WR4Y5rU}}'});

#

can you remove {{ }}

#

loadStripe(environment.STRIPE_KEY, {stripeAccount: 'acct_1G9KlQDV2WR4Y5rU'});

worthy tide
#

I've done all that now getting a 404 error in the front end. This is running in test mode now

#

this is the 404

#

both keys are set to test

storm quest
#

are you using the publishable key of your platform account? probably you can print the key out in using console.log(environment.STRIPE_KEY) making sue that's the right key

worthy tide
#

pk_test_51HZ6bjH3FnYor84o1xouBcMtCPqUgzWpfjgdzl430iLP7X0HNx1x59v0cj9QkapnNP1kv6KNB05fQnJkt7YkMV2y00mnRHC7q1

#

test key

storm quest
#

can you share your full frontend code again ?

#

the publishable key looks correcct

worthy tide
#

async pay() {
this.busyService.busy();
console.log('getting strip key');
console.log(environment.STRIPE_KEY);
if (this.card && this.clientSecret && this.stripeCardValid) {
const card = this.card.element;
const order = this.orderService.currentOrderValue;
const billing_details = { name: order.contactName, email: order.contactEmail };
const payment_method = { card, billing_details };
console.log(this.clientSecret);
const result = await this.stripeService.confirmCardPayment(this.clientSecret, { payment_method })
.toPromise();

  if (result) {
    this.busyService.idle();

    if (result.error) {
      const outcome: IStripeResult = {
        id: this.clientSecret,
        resultCode: StripeResultCodeEnum.failed,
        message: result.error.message
      };
      this.paymentCompleted(outcome);

    } else {
      const outcome: IStripeResult =
      {
        id: this.clientSecret,
        resultCode: StripeResultCodeEnum.success,
        message: 'payment succeeded'
      };
      this.paymentCompleted(outcome);
    }
  }
}

}

#

this is the pay method

#

this.clientSecret = this.paymentService.clientSecret;
this.stripePromise = loadStripe(environment.STRIPE_KEY, {stripeAccount: 'acct_1G9KlQDV2WR4Y5rU'});

#

setting the connected account

storm quest
#

how do you initialise this.stripeService ?

worthy tide
#

this is where its initialized

storm quest
#

It looks like you are using NgxStripeModule which is not a Stripe official SDK, let me check what is that

#

you will need to initialise it with the correct key and stripeAccount: 'acct_1G9KlQDV2WR4Y5rU

#

it looks like it only has the key but not the stripeAccount header

#

NgxStripeModule.forRoot(environment.STRIPE_KEY, {stripeAccount: 'acct_1G9KlQDV2WR4Y5rU})

worthy tide
#

Hi sorry for the delay in getting back to you

#

I just removed the connected account and the settings work fine so there is nothing wrong with the code

I will now add in the connected account again and retest

#

and we get the 404 error again.

storm quest
#

I just removed the connected account and the settings work fine so there is nothing wrong with the code
what do you mean by that?