#longbeard1215
1 messages · Page 1 of 1 (latest)
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.
- longbeard-ach-fees, 3 days ago, 16 messages
Hello
Hello
Can you provide the specific example? Then I can take a look
One moment
pi_3OdzlNFQyhzEatZS06dSiFss
Dashboard shows $.50 fee returned.
That is not in the failed_balance_transaction
Yeah there should have been a separate balance transcation generated for that fee refund
Don't believe it is within the actual failed payment transaction
Have you listed out balance transactions?
No I have not. Our software assumes the payment intent/charge will hold the data we need to find related transactions.
If it is a separate balance transaction does that mean there is no relation to the intent/charge that it for?
It appears that way. I'm indeed surprised that it isn't associated to the failure_balance_transaction
Can you show me the JSON response for that transaction when you retrieve it?
Should be fine
Attached
Hmm wait I do see it there?
Oh nvm
So yeah I believe this is caused by the application fee refund being a separate balance transaction type
The premise is that you could refund an application fee arbitrarily
It wouldn't necessarily be associated
I think I see a path. If I look in the dashboard at fee_1Oe2CgFQyhzEatZSY9gobxYb I see it refunded
Yes that's correct.
That is what would be associated to the separate balance transaction
I am assuming there is an API call to grab that fee id and look at a structure
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 see the call. Still odd that it's not in the failed_balance_transaction imo.
We are also seeing varying logic on these. Some refund the fee, some do not. I don't know why.
On a related note. Is there any link between paymentIntents and Instant Verification Fees? I cannot find one.
Very frustrating as we can only assume this transaction generated a $1.50 fee since that fee only shows in the payout lines items and I see no way to relate the fee to the transaction
If you are seeing varying logic then I would need to see specific examples.
And no, there isn't a direct link for Instant Verification fees since they are applied in bulk daily
sure. pi_3OML4aFNldbU3CoE0zbP3Ck5
Did NOT refund the $.50
As with the first one. A failed ACH. Stripe processing fee returned, failure fee assessed. First one returned the Application fee. Second one ne did not.
Taking a look
Okay I can see that your platform was in a feature to previously not reverse the app fee but then that feature was removed.
Not sure if you have been in communication with anyone internally about that over the past couple months?
I am not sure what you are referring to - I am the lead programmer and handle all the code
Are you saying a setting was changed or something?
Yeah looks like there was a configuration change on your account internally which is the reason that one of the app fees was refunded and one was not. I don't have any further context on that -- if you want a more detailed explanation of why that happened then you would need to reach out to our Support team via https://support.stripe.com/contact/login so they can follow up with the owning Product team internally that made that change.
OK. So I am clear. You mean someone on the Stripe side changed the configuration to reverse the fee?
Can you tell me what date so I can inquire further?
Looks like ~2 weeks ago
And is there any language I can use with support so they know what I am referring to? A setting name, etc...
No sorry, I would just describe the issue and provide the two PaymentIntent IDs that you provided to me and they will be able to investigate.