#xfechx
1 messages · Page 1 of 1 (latest)
Hi ynnoj
my first question:
with payout.created and payout.paid
what is the difference? Is payout.created means that the money is already on the way to the bank account?
or is it when it is only queued to be sent (2 days afterwards, etc)
payout.created is fired when the actual Payout object is created, and when that is depends on your payout schedule
When is the payout object created?
i will send a screenshot and can you tell me if payout has been created?
I can see that payout events do not appear on logs?
Can you tell me if payout.craeted has already been sent in this scenario?
the API is not entirely clear about this
*API docs
Again, depends on your payout schedule. If manual, when you create the Payout either via the API/Dashboard. If automated, then it'll be per the schedule (daily, etc)
Click the Payouts link on the left
I don't think there's been a Payout created (hence the estimated future payouts)
ok
that was my question.
So when it is listed there, it is still haven't created
I now have another question
I am having trouble with a 500 server error code, even if in my server I set it to output php errors
I had never this happened before
I have try catch so that errors are processed and so that I receive error messages, not server errors
And lastly: How can I trigger a payout.created from test dashboard?
Are you making an API call when receiving the 500 error?
You'd create a payout
it's from a webhook
I have the same code in many more servers/websites, and doesn't happen elsewhere. I am getting a error from stripe API.
in this case the lack of that specific account filtered to use max_ocurrences, but that is not really the problem, the problem is that Stripe is receiveing a 500 error, rather than a OK response from the try, catches
my code is supposed to try catch all stripe calls errors when they happen, and it does work elsewhere, just not on that specific account.
I recently changed nginx to use http2 not sure if that has anything to do
how?
via dashboard?
how can I make money available in test mode
I tried with stripe CLI and it mentions there is not enough funds
Again, depends on if you're using manually payouts
You'd use this test card: https://stripe.com/docs/testing#available-balance
Can you share an Event ID (evt_xxx) which you've had trouble processing in your webhook?
evt_1L4rRgEchYtuJn0PxXBMtwTj
Yep, looks like your webhook endpoint is returning a 500 error
You can see the response we're receiving here: https://dashboard.stripe.com/test/events/evt_1L4rRgEchYtuJn0PxXBMtwTj
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Something in your webhook code is throwing an error. You'd need to work to debug what code is causing that error
Regardless of whether you catch the error or not, the server will still respond with a HTTP status indicating an error (500 in this instance)
hmm
The 'catching' part ensures that the error is correctly handled in your application and it's logged for you to debug and resolve
if it was try catching properly, the webhook would not fail
it would not return a 500 error
that is the purpose of a try , catch
That's not true I'm afraid
hmmm? I have been using webhooks for more than 7 years..
with stripe
the purpose of try catch is to not receive a server error
is to receive a error message and display it cleanly instead of a server error
You're not receiving a server error from Stripe, you're sending us the 500 error
Because your application is erroring
i think you aren't understanding me
Then I'm confused. The source of the error is in your webhook code
I already said that since the begining. But the error is being sent from Stripe, it is a Stripe error like "transfer failed" or "parameter not found"
usually, in the webhook logs. I can see the Stripe error messages, in this case I am only seeing a 500 error
which makes the webhook retry
not to succeed
so my issue is to know why in this specific case, my try catch is not even working
only on this server
on this account
We're not sending an error. We're sending you a customer.subscription.created event which your webhook should be processing. However something in the code is throwing an error and as such is returning a 500 response to us
I think i need to speak to someone else
This is marking it as a failed delivery, and thus retries are made
i already know that.
My specific problem, is that for some reason, it seems my try catches aren't working
on this specific scenario
Can you share the code? Perhaps I can help debug the issue
usually, I go to the webhooks page, and can see the issue in the response part
I can see my debug messages there, and Stripe error messages (properly catched) there.
that has ALWAYS been the case.
in this case
I am ONLY seeing 500 server error
Yup, that's where we log the response received from your webhook. In the case of evt_1L4rRgEchYtuJn0PxXBMtwTj, the response is:
{"code":"internal_server_error","message":"<p>There has been a critical error on this website.<\/p><p><a href=\"https:\/\/wordpress.org\/support\/article\/faq-troubleshooting\/\">Learn more about troubleshooting WordPress.<\/a><\/p>","data":{"status":500},"additional_errors":[]}
Yes I can see that, that's why i am here.
Ok, and as I explained that's an error thrown and returned from your webhook code. If you share the code, perhaps I can help identify the issue
the code is too complex,
I can't really help identify the issue without the webhook code
ok, is there anyone that can help me?
You don't seem to understand the issue
I don't need you to look at my code
thanks but it is something else
I will make another test and will show you, one sec.
no worries, but I don't really see how anyone here could say why try/catches in your own code might not be executing
if you want a random pointer, in one version of our PHP library we changed the names of the Exceptions classes so if you updated the stripe-php dependency without changing the code you use to account for the new names, your catches might not catch the new errors . https://github.com/stripe/stripe-php/wiki/Migration-guide-for-v7#changes-to-exceptions . just a guess
yeah i think that might be the case..., but I don't catch in this case specific Stripe errors
just catch the stripe error, and display it on the output
I see
sure
Can I do this?
$stripe->charges->create([ 'amount' => $amount * $percentage_fee, 'currency' => $currency, 'customer' => $external_customer, 'description' => get_bloginfo('name') . ' Application Fees', 'metadata' => array( 'API'=> $api, 'Test'=> $test_mode, 'Link'=> get_bloginfo('url'), ) ]);
Or do I forcedly need a source?
Also, how can I enter metadata to a payout?
and then process it with a webhook?
first payout.created and then payout.paid ?
when payout.created, I can write metadata, and will it be conserved in payout.paid, then I can listen with webhook for it and use metadata to process functions afterwards?
ok that's like 5 questions at once so give me a sec
that might work, if the customer has a default source. Passing only the customer ID will charge that customer's default source if they have one.
Note, relatedly, that API you're using (charges->create) is completely deprecated for several years now, you should be using PaymentIntents and/or Checkout.
you listen for the payout.created webhook event and then call the update Payout API to set metadata
yes
@meager lintel
Ok, how can I translate to payment intent?
I use checkout sessions too, and payment links, but in this case I need to charge customer in the backend
after a payout has been made
the reason being is that the platform is in Canada, and I cannot do X-border transfers, I think you both helped me with this question a few days ago, thanks.
But my app/service needs to charge the platform a percentage fee
it is not ideal, but I cannot find another way to do it.
https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method shows how you create an off_session PaymentIntent to charge a saved card
Ok, I can see that it creates the payment intent is that just like a charge?
and can i omit payment method?
it's a state machine for charging a customer's payment method, it does end up creating a Charge object
and what is confirm ?
no you can't omit the payment method, you have to supply it to tell us what card we should charge
why is it better to use than charge?
confirm is the action that actually attempts the charge
because it supports 3D Secure
so the customer needs to do something?
they might
if you use PaymentIntents you can handle that requirement
if you use Charges directly you can't, the charge just declines
Ok, if I use payment intents, and I don't want the customer to interact, because it will be a charge on the backend for fees..
how do I do it ?
you use the guide I linked
you (and Stripe) don't decide if the customer has to 'interact' (perform 3D Secure) since it's generally the bank who enforces that, as it's a regulatory requirement in some parts of the world. Generally you will get 'exemptions' so that off-session payments like that don't need an action. Just make sure you're using our documented default integrations for saving the card and charging it later.
If my app uses checkout sessions, without payment_method
will the source be saved?
automatically?
It depends, you have to specify if it should be setup for future use, but not all payment methods support that
You can review the integration options to see which support setup_future_usage
https://stripe.com/docs/payments/payment-methods/integration-options#additional-api-supportability
(Checkout uses payment methods API, not Sources)
What specifically are you trying to accomplish thats not been covered?
Will this make sure that there is always a source?
``if($event->type == 'checkout.session.completed'){
echo "--- EVENT: CHECKOUT.SESSION.COMPLETED";
try{
$payment_link = $event->data->object->payment_link;
$customer_email = $event->data->object->customer_details->email;
$customer = $event->data->object->customer;
$setup_intent = $event->data->object->setup_intent;
if(!empty($customer) && !empty($setup_intent)){
$setup_intent_object = \Stripe\SetupIntent::retrieve($setup_intent, $connected_account);
$default_payment_method = $setup_intent_object->payment_method;
echo ' --- default payment method: ' . $default_payment_method . '---';
Stripe\Customer::update(
$customer,
[
'invoice_settings' => [
'default_payment_method' => $default_payment_method
],
],
$connected_account
);
} ``
What do you mean "there is always a source"?
You cant do that if, for example, you use a single-use payment method
Also - the other day I realised that after a failed invoice; my app provides a notification email with the stripe url for that invoice, when the customer paid it, it didn't make that payment_source the default
for other subscriptions for the same customer
Correct, the hosted invoice page (the payment page where that URL points) has different behaviour. You should make sure you manage the intended customer default explicitly.
What do you mean by "manage the intendd customer default explicitly"
I mean, your application logic should manage the customer invoice_settings.default_payment_method explicitly to be what you want, just like you do in the webhook endpoint after checkout
It depends on what you're doing, there is no single answer to that
To be more precise, I interpreted your question to be "what is the best time to update the customer object to set their invoice_settings.default_payment_method?"
If you actually mean to update a Source object (https://stripe.com/docs/api/sources/update) then that's quite different, but still depends on what exactly you're trying to do.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Can I accelerate payout.paid in test?