Use Order API to create recur directly for Formbuilder payments

[mattwire]

Overview

When Formbuilder payments was first written Order API did not support recurring contributions. Now it does. So let's use it!

Before

Separate function, after Order API called

After

Created using Order API

Technical Details

Comments

[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 🔗

[ufundo]

@mattwire I've been trying to get my head around this and #35996

I like the general idea here a lot and the code looks good to me.

But I'm stumbling on the following discrepancy between Contribution and ContributionRecur:

Contribution:

• Contributions are effectively just invoices = amount payable + date = commitment to pay
• they are neutral with respect to Payments, which are separate
• you can set up a Contribution without paying it
• you could use multiple different payment processors to pay different chunks of a contribution

ContributionRecur

• for ContributionRecur it is both the "repeating invoice" = commitment to pay certain amount on a certain date
• and it is directly linked to a specific payment processor, and often has payment processor related details ("subscription id"...)
• that makes a mockery of the otherwise clean division in Afform Contributions between "create the contribution" and "pay for the contribution"
• currently it's slightly fudged - create the ContributionRecur without a payment processor id, and then later update if needed (see e.g. https://lab.civicrm.org/extensions/paypal/-/blob/dev/Civi/Paypal/CheckoutOption/PaypalComplete.php?ref_type=heads#L260 )

Are you at all worried about this discrepancy? Do you have any thoughts on how to handle it?

Does Order API for recurring contributions allow setting the payment processor (and associated details)?

[mattwire]

ContributionRecur

• for ContributionRecur it is both the "repeating invoice" = commitment to pay certain amount on a certain date
• and it is directly linked to a specific payment processor, and often has payment processor related details ("subscription id"...)

ContributionRecur is the subscription schedule and payment method. In the case of a direct debit you can think of it as the "mandate". It is not an invoice but you can expect invoices to be opened because of it.

• currently it's slightly fudged - create the ContributionRecur without a payment processor id, and then later update if needed (see e.g. https://lab.civicrm.org/extensions/paypal/-/blob/dev/Civi/Paypal/CheckoutOption/PaypalComplete.php?ref_type=heads#L260 )

It's only fudged because afform payments doesn't add the payment processor ID, quickform does. Because Order API didn't support recurring until early this year you had to do separate calls to create the recur.

Are you at all worried about this discrepancy? Do you have any thoughts on how to handle it?

Does Order API for recurring contributions allow setting the payment processor (and associated details)?

This PR will actually need a bit of rework once #35996 is merged - as long as the params are passed into order api they will be saved.

[mattwire]

Marking draft pending merge of #35996