refund_proposal_and_payment_aligment

[PedroDiez]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

This PR covers proposal for refund functionality.

• It provides a design for both total and partial refunds, allowing for asynchronous model in business proceesing
• Events Model covered
• Exceptions Model covered
• Some alignment within commonalities included
• Considering remainingAmount not refunded in Payment resource (i.e. API)
• Considering amount (minimum:0.001) and taxAmount (minimum: 0) to be non-negative
• PhoneNumber aligment in Carrier billing. Exceptions added (draft input to check the whole model after).
• merchantIdentifier model, 422 exceptions and more description for refund
• polimorphic model for refund
• new proposal for remaining payment amount

Which issue(s) this PR fixes:

Initial Proposal - Baseline for:

Fixes #104 Fixes #158

2024-05-15

Fixes #153 (commit 7b224ea01003e4d8aac1be692f12c34add63c293) Rename status to paymentStatus and refundStatus. Also cover amount (minimum:0.001) and taxAmount (minimum: 0) to be non-negative in refunds (commit d12b4cfcf29a5358c64fcad249e9617a11500d57)

2024-05-24/25

PhoneNumber aligment in Carrier Billing (commit bb99437f73199e8e70dd7dffd1acd838538e925a) merchantIdentifier model in Carrier Billing Refund, 422 Exceptions, more description (commit 659b2aa46ef4dd0494a8576e47952cea64761601) polymorphic refund model (commit 08837a86b7ab472aa9d84c7bbcab8cdff022ca5b) new proposal for remaining payment amount (commit efe24441d606325a7b55d1c24a464f1a54b4a209)

2024-06-10/11/12

Alignment with Commonalities PR#214 (x-camara-commonalities header) and Notifications CloudEvent Model (commit 4d03b249acb8eddfb15a12681897ff5c936eb0e3) Inclusion of paymentItemId concept ( commit 9c723cd6c8f37cbf5ff6dac146d2343b6dffc5e4) fixing some typos and missings in error exceptions (commits e2be5764777e87a7ab10771617424fcd3b7db7a9, 8d079e383cdeec649e63cdc07b2c646099a81ae1 and a647deaa050492aae4a662710decddbb0a764023)

2024-06-19

Description enhancements and description.info alignment with Commonalities ICM output (# Authorization and authentication section) (commit 85a008a0a6c619a6521dd2a759ae4c161fbffcfc) Semantic enhancements (denied refund in ASYNC context, remainingAmount behaviour, based on Ludovic comments/suggestions) (commit 9377d6cacf22c5e182ce9508f89c80bc8d777f34)

2024-06-21 Fixes #154

Commonalities alignment errors (#154) and endpoint versions (commit 8c230ba20700a15605abd94f748fcebc6ea658f2)

2024-06-27

Fix typo un refund-completed event (paymentDate should read refundDate) (commit 8cfe775ce8e556e15094eb8fe0d92c9e1932d7f4)

Special notes for reviewers:

[github-actions[bot]]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ OPENAPI	spectral	2		0	3.95s
✅ REPOSITORY	git_diff	yes		no	0.05s
✅ REPOSITORY	secretlint	yes		no	0.95s
✅ YAML	yamllint	2		0	0.9s

See detailed report in MegaLinter reports

_MegaLinter is graciously provided by _

[bigludo7]

One quick question.... what is the correlation between refundDetails.refundItem and paymentDetail.paymentItem ? I guess we expect a strong correlation meaning that if I have 3 payment item I could have a refund only for the second item right? As such in order to have this correlation I'm wondering if we should not add a paymentItem.id in paymentItem and refer this in refundItem. Perhaps this is 'too much' but got this comment in looking in refundItem and how to use it.