Payment Create - Prevent duplicate payments recorded by concurrent Payment::create calls

[mattwire]

Overview

A payment processor's webhook notification for a charge can race a synchronous front-end/back-office confirmation of the same charge (e.g. paying an existing pending contribution via CRM_Contribute_Form_Contribution_Confirm), both calling Payment::create for the same contribution at once.

The existing 'contribution already completed' guard only re-checks status right before completing the order, which isn't atomic, and doesn't stop the FinancialTrxn payment row itself being created twice earlier in the function.

Add a per-contribution lock via Civi::lockManager() around create(), and reject a second payment with the same trxn_id for a contribution. Includes a regression test using APIv4 Payment::create/get.

Found with stripe extension on a client site (webhook for payment completion comes in quicker than contribution page confirm processes and they sometimes end up concurrently recording a payment).

Before

No lock.

After

Lock around payment::create

Technical Details

Comments

Are there any situations where we would legitimately have a second payment with the same trxn_id?

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

PR commands & links...

• /rebase <branch-name> will rebase your branch and change the base of the PR.
• /squash will combine all commits (keeping only the first commit messsage).
• /port <branch-name> will create a copy of this PR against a different branch.
• /lintroll will automatically fix linting errors, amending commits as needed.
• retest this please will rerun the tests and rebuild the demo site.
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[eileenmcnaughton]

@mattwire this makes sense - there seems to be a unique index on civicrm_financial_trxn.trxn_id - so that that answers that....

The user experience could be a bit gross if the web hook gets there first as I'm not sure the exception is caught / handled

[mattwire]

This is the branch that captures on the webhook side - https://lab.civicrm.org/extensions/mjwshared/-/merge_requests/76.

I'll look into the user side.

[mattwire]

@eileenmcnaughton I've just posted an alternative here - #36426 - feels a bit cleaner?