CIVIMM-494: Fix reconcile job processor_type parameter

[erawat]

Overview

The reconciliation scheduled job default parameter used [Stripe,2] but civicrm_payment_attempt.processor_type stores Stripe Connect (the PaymentProcessorType name). This mismatch meant the job would never find stuck Stripe payment attempts.

Before

Job parameter [Stripe,2] → queries WHERE processor_type = 'Stripe' → 0 results (actual value is Stripe Connect)

After

Job parameter [Stripe Connect,2] → queries WHERE processor_type = 'Stripe Connect' → finds stuck attempts correctly

Technical Details

• Stripe Connect is the value from CRM_Stripe_Helper_Constants::PROCESSOR_NAME used when creating payment attempts
• The Stripe extension's handlers now accept both Stripe and Stripe Connect for backwards compatibility (see uk.co.compucorp.stripe PR #275)
• This PR updates the default for new installations — existing sites with [Stripe,2] will still work due to the backwards-compat change in the Stripe extension
• Found during E2E testing of D8 (Reconcile stuck attempts)

Comments

Existing sites do NOT need to update their job config immediately — the Stripe extension's backwards-compat change handles both values. However, updating to [Stripe Connect,2] is recommended for consistency.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue where the scheduled job designed to reconcile stuck payment attempts was failing to identify Stripe transactions. The problem stemmed from a mismatch in the processor_type parameter, which incorrectly used "Stripe" instead of the actual "Stripe Connect" value stored in the database. By updating this parameter, the job can now correctly query and process stuck Stripe payment attempts, ensuring proper reconciliation.

Highlights

• Reconcile Job Parameter Fix: Corrected the processor_type parameter for the payment attempt reconciliation scheduled job from Stripe to Stripe Connect to accurately match the value stored in civicrm_payment_attempt.processor_type.
• Documentation Update: Updated the inline documentation for the processor_parameters format to reflect the correct Stripe Connect value.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly fixes a bug where the payment reconciliation job used the wrong processor name for Stripe, preventing it from finding and processing stuck payments. The changes update the default job parameters and associated documentation from 'Stripe' to 'Stripe Connect'. The fix is accurate and addresses the problem. I have added one comment regarding the hardcoded processor name, suggesting a more robust approach for future maintainability.