feat(router): enhance conflicted payment handling - #14288
AkshayaFoiger wants to merge 16 commits into
Conversation
…on and overcapture
8e4d491 to
9e0445d
Compare
| split_payments: None, | ||
| webhook_url: None, | ||
| merchant_order_reference_id: None, | ||
| is_overcapture_enabled: None, |
| split_payments: None, | ||
| webhook_url: None, | ||
| merchant_order_reference_id: None, | ||
| is_overcapture_enabled: None, |
| payment_intent: &storage::PaymentIntent, | ||
| payment_attempt: &storage::PaymentAttempt, | ||
| ) -> Vec<enums::ManualUpdateIntentStatus> { | ||
| use enums::ManualUpdateIntentStatus as Status; |
| pub payment_id: id_type::PaymentId, | ||
| /// The statuses that a manual status update for this payment may currently target, | ||
| /// computed from the payment's capture method and requested/received/capturable amounts. | ||
| pub eligible_statuses: Vec<enums::ManualUpdateIntentStatus>, |
swangi-kumari
left a comment
There was a problem hiding this comment.
connector changes looks good to me.
|
[should-fix] [should-fix] The new [should-fix] The newly introduced |
3d51e8f
Type of Change
Description
Chnages done in this PR
Move the integrity failure error response to 2xx
Store
amount_receivedin case of conflicted stateAdd an endpoint that communicates, the next possible status a payment can be updated to in case of manual status update
JWT and Merchant Api Authentication
UNSPECIFIEDstatus received from UCSThis PR does not cover
Additional Changes
How did you test it?
Conflicts are tested by hardcoding response value
A conflicted UCS payment
Response
Manual status update
Response
Test conflicted refund via hyperswitch connector
Test conflicted capture via ucs
Checklist
cargo +nightly fmt --allcargo clippy