Having set up the Recurring process on Smashpig and looked through the recurring charge process on Civi, I'm certain that the CRM_Core_Payment_SmashPig civi class would be able to charge the Dlocal recurring card payment using the createPayment method in the Dlocal CardPaymentProvider class. So far I don't see any need for any Dlocal specific tweaks on the CRM_Core_Payment_SmashPig civi class.

The Dlocal CardPaymentProvider's createPayment method checks for the presence of the "recurring_payment_token" (this is the "card_id" from Dlocal) in the request params, which it uses to determine if the payment transaction is a recurring charge payment. If it is a recurring charge payment, the payment is captured in a single API call, else the payment is divided to the Auth/Capture steps for fraud checks.

This task would be closable after running an end to end test upon completion of T324297. The end to end test would cover:

• The recurring donation on Donation Interface Frontend.
• Consuming the queues and ensuring the recurring Donation has a row in the civicrm.civicrm_contribution_recur table afterwards. Get the id of the recurring donation on this table.
• Trigger a charge for the Dlocal recurring using this

drush @wmff -vv cvapi job.process_smashpig_recurring contribution_recur_id={id}

Hi @Damilare. I've been reviewing @AndyRussG's DonationInterface dLocal recurring patch, and I'm wondering if the requirement to use the 'fiscal_number' needs to be accounted for in the CiviCRM SmashPig Recurring extension when making recurring dLocal charges? I might have misheard, but I think you said on a call a few weeks back that we need that field to charge recurring payments.

When looking through the CiviCRM SmashPig Recurring extension code, I noticed the 'processor_contact_id' param is being used as part of the internal mapping in this extension here. I wonder if we need to do something similar for fiscal_number.

Hi @jgleeson, yes the document field is required to process the recurring charge. Thanks for the link to the mapper, I think we'd also have to add the additional param in the getPaymentParams as well, I've created this task T331288 to get that done.

The other challenge is that we don't currently save the contact's document in the civicrm_contact table, we were discussing using the processor_contact_id on that call. Given that is in use already in your link, should we create a new column or can we use the user_unique_id column?

Change 894693 had a related patch set uploaded (by Ejegg; author: Ejegg):

[wikimedia/fundraising/crm@master] Save fiscal_number and use for SmashPig recurring

https://gerrit.wikimedia.org/r/894693

Change 894743 had a related patch set uploaded (by Ejegg; author: Ejegg):

[wikimedia/fundraising/crm@master] Add country to recurring charge calls

https://gerrit.wikimedia.org/r/894743

Change 894743 merged by Ejegg:

[wikimedia/fundraising/crm@master] Add country to recurring charge calls

https://gerrit.wikimedia.org/r/894743

In T324298#8648485, @Damilare wrote:

Having set up the Recurring process on Smashpig and looked through the recurring charge process on Civi, I'm certain that the CRM_Core_Payment_SmashPig civi class would be able to charge the Dlocal recurring card payment using the createPayment method in the Dlocal CardPaymentProvider class. So far I don't see any need for any Dlocal specific tweaks on the CRM_Core_Payment_SmashPig civi class.

The Dlocal CardPaymentProvider's createPayment method checks for the presence of the "recurring_payment_token" (this is the "card_id" from Dlocal) in the request params, which it uses to determine if the payment transaction is a recurring charge payment. If it is a recurring charge payment, the payment is captured in a single API call, else the payment is divided to the Auth/Capture steps for fraud checks.

This task would be closable after running an end to end test upon completion of T324297. The end to end test would cover:

• The recurring donation on Donation Interface Frontend.
• Consuming the queues and ensuring the recurring Donation has a row in the civicrm.civicrm_contribution_recur table afterwards. Get the id of the recurring donation on this table.
• Trigger a charge for the Dlocal recurring using this

drush @wmff -vv cvapi job.process_smashpig_recurring contribution_recur_id={id}

I was able to put in a successful recurring charge, thanks to the changes made by @AndyRussG and @Ejegg. I believe this should be closable now.

https://localhost:9001/index.php?title=Special:DlocalGateway&appeal=JimmyQuote&payment_method=cc&recurring=1&uselang=en&language=en&currency=INR&amount=5005&country=IN&first_name=Jimmy&last_name=Wales&fiscal_number=AAAAA9999C&email=jwales%40example.com&debug=true return {"code":5001,"message":"Missing parameter: payer.phone","param":"payer.phone"}, should we mock one here like '877 600 9454', since phone number is not essential as city, https://gerrit.wikimedia.org/r/898234.

Also even through add the phone, drush @wmff -vv cvapi job.process_smashpig_recurring contribution_recur_id=xx return [error] => CreatePayment failed tried with both in and br

P.S. As ejegg mentioned, we don't usually worry about people manually manipulating the URL, we generally rely on the donatewiki form or the banners to offer recurring only when it's available, so since India is not allowed recurring with cc recurring, no need to update the patch, so abandon that patch.

Change 898234 had a related patch set uploaded (by Wfan; author: Wfan):

[wikimedia/fundraising/SmashPig@master] Only convert to subscription if upi also set a default phone for india in cc

https://gerrit.wikimedia.org/r/898234

Change 898234 abandoned by Wfan:

[wikimedia/fundraising/SmashPig@master] Only convert to subscription if upi, only set wiki phone as default for india cc

Reason:

No need to worry the manually manipulated URL

https://gerrit.wikimedia.org/r/898234

No need to do this for IN (we control this recurring country from ways to give, so patch abandoned), tested well with BR