Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| - The value can be negative.REFUND_REVERSE | ||
|
|
||
| #### Charge Pending Value ([`transactionItem.chargePendingAmount`](/api-reference/payments/objects/transaction-item#transactionitemchargependingamountmoney---)) | ||
| - When an `CHARGE_REQUEST` event occurs and there is no `CHARGE_FAILURE` or `CHARGE_SUCCESS` event is: value increases by the `REQUEST` event's amount. |
There was a problem hiding this comment.
question: isn't this value impacted by refund and chargeback as well?
There was a problem hiding this comment.
No, CHARGEBACK does not influence charge_pending_amount
9fef408 to
561d863
Compare
561d863 to
92b756f
Compare
f41962c to
26173b0
Compare
| #### 2. Pending Amounts: | ||
| - Pending amounts (`authorizePendingAmount`, `chargePendingAmount`, `refundPendingAmount`, `cancelPendingAmount`) are increased only if a `REQUEST` event exists for the corresponding PSP reference. | ||
| - If a success or failure event is also associated with the same PSP reference, the system assumes the requested amount has already been processed, and the pending amount will not be increased. | ||
| #### 3. `SUCCESS` and `FAILURE` Events: |
There was a problem hiding this comment.
Wouldn't be also good to mention that in case of the SUCCESS, the amount will be subtracted from the "previous" value?
I mean, we have a transaction with event AUTHORIZE_SUCCESS and amount 100. TR has authorizedAmount:100, chargedAmount:0. Then we receive the event CHARGE_SUCESS and amount: 100. The 100 will have an impact on authorizedAmount. TR will have: authorizedAmount:0, chargedAmount:100 (as we subtracted the amount from CHARGE_SUCCESS from authorizedAmount and added it to chargedAmount)
There was a problem hiding this comment.
Okay, I see that you deeply explained it below. So the question is: Do you think, that this is wort also to mention it here?
There was a problem hiding this comment.
I added a note about that in Calculation process part
|
|
||
| This logic ensures that transaction amounts reflect the current state of the transaction based on its event history while accounting for both processed and pending actions. | ||
|
|
||
| ### Calculation details |
There was a problem hiding this comment.
Maybe worth explicitly say, that we are talking about the events returned by APP - I mean, events that have psp_reference provided by App. For example, you could still see X_request event created by Saleor when calling the app, but it is not included in calculations until receiving at least psp_refernce from payment app 🤔
There was a problem hiding this comment.
I might not be clear here.
I was meaning the situation when saleor creates X_REQUEST event (like calling charge-request, or refund-request). The event's amount will not be included in calculations until receiving the SUCCESS response from the app. As this action is called asynchronously (I mean a situation when calling this action from dashboard), we can have a TR like:
TR: chargedAmount 100, refundAmount:0
Event1: amount: 100, type CHARGE_SUCCESS, pspRef:123
Event2: amount: 100, type: REFUND_REQUEST, pspRef:null
As event2 was created by Saleor, and we're proceeding the refund request right now, the transaction.chargedAmount , transaction.refundedAmount are not impacted.
There was a problem hiding this comment.
I added a note about that
b8be7d8 to
eaccd38
Compare
eaccd38 to
27ec342
Compare
a9923d6 to
5f878a4
Compare
Explain transaction amount calculations