#sean-api-request
1 messages · Page 1 of 1 (latest)
Can I get that within the portal?
do you mean Stripe Dashboard? then yes
https://dashboard.stripe.com/logs
I see it on the main developer overview
But when I click it it says No results found
And when I show all failures it is not in the log list
can you link me to which specific request you think that failed?
I can't figure out from a bunch of failing GETs which one was failing
and please share a request ID, can't parse much from just a screenshot
It does not show in the list
It shows on the Developer Dashboard
But not in the log
can you click into that? it should be possible to click into and see the full request (in your URL) like req_123
let's start here: #946523455820558426 message
you'll see lots of requests, looks like you have plenty of errors
let's start with ONE of those requests and go from there
can you share one request ID, which I assume is blocking your livemode integration?
None of the requests logged are an issue
The request I am concerned about is not lited in the log
ok let's start there then, what request are you concerned with? what endpoint would it be hitting?
v1/checkout/sessions"
Here is the building of our request
client.DefaultRequestHeaders.Add("Stripe-Version", new[] { "2020-08-27;us_bank_account_beta=v2" });
client.DefaultRequestHeaders.Add("Authorization", new[] { "Bearer " + _stripeClient.ApiKey });
And the contents
new KeyValuePair<string, string>("payment_method_types[]", "us_bank_account"),
new KeyValuePair<string, string>("payment_method_options[us_bank_account][verification_method]", "instant"),
new KeyValuePair<string, string>("mode", "setup"),
new KeyValuePair<string, string>("customer", customerId),
new KeyValuePair<string, string>("success_url", successUrl + "?sessionId={CHECKOUT_SESSION_ID}"),
new KeyValuePair<string, string>("cancel_url", cancelUrl)
ok so CheckoutSessions
next, going back to the request logs page: change API Method to POST and try that and share any request ids
req_h7pz8XKcGv4SOn
There are many
This is one for setting up a Customer
req_NhJ6FSTKK4XwCj
This is for a setup_intents
Here is one for the Candian Bank Checkout req_gWdZzPmsY3l2Xk
are these error'ing requests?
yeah sorry we're not getting to the right thing here. That was just a diff erroring request for an action in the Dashboard
are you the developer working on your integration?
I am the team lead. The original Dev is out of office at the moment
Our workflow creates a customer and then generates a checkout session
CAD is working as expected
ACH is failing with a bad request when creating the session
We have been using a Dev instance and it has been workign for several monthls
back to the Logs page
can you add a filter in that page for the endpoint: /v1/checkout/sessions
so that it only lists POST requests that error out, to that endpoint
The QA instance configuration was fnished today and our code is failing against it
There are zero
If I list all requests, I see the 2 successful ones for CAD
did you use new API keys when you did this:
We have moved from our Dev to QA Stripe instance
since Stripe has no Dev/QA instances, only live and test moe
I know, but we have multiple instances representing our environments
We have a Dev instance, QA Instance, and Prod Instance.
We use the Dev and QA Instances in "Test" mode
from the code snippet above, can you add these lines to get the request ID from the request made by your code
https://stripe.com/docs/api/request_ids?lang=java
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
I can try looking that up
That is going to be difficult and take some time since it is in our QA environment
But I can go down that path
yep I recognize but otherwise we're not sure what we're looking for since the Dashboard isn't showing stuff and I assume either things are happening in the other live/test mode or in a diff account due to (somehow) a diff API key being used
I am guessing there is some configuration difference between teh 2 instances
I will go ahead and add some logging around this so that we can get some more information
that is the other thing, you can log out (on your end) what
_stripeClient.ApiKey
is (don't paste it here though!) and compare if your DEV/QA instances possibly use diff API keys
They do use different API Keys
ah that might be the issue (one account in a beta, the other not) but let's confirm once you log stuff
oh also
log out ``` new KeyValuePair<string, string>("customer", customerId),
the `customerId` you pass too, that is a ~safe thing I can look up and try to trace where it was passed
cus_LDFbNLhz8MGDrj
cus_LDEsLw011Hqiy1
I tried with both of these customers
I think you are onto something
This is out Dev Instance API Version Screen
Our QA INstance looks different
mind sharing the account IDs of each (fine to share here, they are not sensitive, they are like acct_123 and you'd find them under https://dashboard.stripe.com/settings/account
one of yours should be acct_1KR...wnL (grabbed it from the Customer above)
so I just need the other
thanks, looking
I have also been messaging out Implementation specialist
I think she might have just made some changes
ok so your QA account does not have the new ACH gates that your dev account has, so that is possibly a big one. Looking for the actual /v1/checkout/sessions request though to confirm
OK that makes sense
Without having the Gate it probably is not even getting logged
I guess I meant not getting displayed in the portal for us to see
ah you're right, idk why I always thought they do get logged but this one isn't! just confirming which account this request was made on but yeah I do see the params you passed on an ACH CheckoutSession for one of the Customer IDs above
error_message=beta_header_not_permitted error_type=invalid_request_error
this is a request on the acct_1KRJDfEfB0rwywnL account aka QA
which doesn't have the ACH gates so yeah that is the issue I expected earlier: #946523455820558426 message
def reach out to your Implementation Consultant and have them apply the same gates from acct_1JrMjDFXP9IgMuNp to acct_1KRJDfEfB0rwywnL for parity