Great Christine. Looking forward to converting the rest !

Looks good on donate wiki!

I agree with Michael. +1 Zero's work.

Not a blocker from my POV

My mistake!

This seems to be related to 3DS declines. More transactions are getting through to the issuer/less abandonment and so we are seeing more Non Pares declines. I'm closing this task as there is nothing for us to do.

ok, that's good news! I didn't compare it. Thanks

Awesome! I was just looking at some transactions to test this myself! Great!

Hi All, how is this going? May I get the 10 or so transactions we converted so I can track them?

Hi David/FRTech. We have several recurring donations cropping ups that need some messaging around failed donations. It would be really good to have this messaging for Donor Services to have as a tool. Since Paypal has shut off their messaging, we are getting inquires from Donors about this and we need a way to send out a message. Is this anywhere near close to being prioritized? Many thanks

From Paypal: Generally with recurring transactions we do require a secondary funding source as a back up for these types of transactions. Also we do try up to three times to pull the funds; if we are unable to capture payment we will then cancel the recurring payment. I have filed a ticket with our engineers just in case there was an problem and it would need to be fixed.

4.20.2020. Hello, I wanted to update this task for as we are running Big Bundle, NO, AT, BE and SE campaigns right now, I am seeing a resurgence of the Fredge process scrambling results or pulling up blanks on many transactions. This makes researching the fraud results each day difficult and makes the manual process 2-3 times longer than it does when the Fredge data pull process just works. Hoping this can make it into a Sprint before Big English this year. Thanks!

Thanks Michael, I am raising with Paypal now.

@Cstone @Ejegg Hi, I have learned that the Fundraising team is looking to launch Israel in the near term. Do we believe this issue to be resolved if this goes forward in the next few days?

I have captured all of the pending recurring transactions manually in the Adyen portal. Elliott confirmed we will make API adjustments to settle cards in the future and IDeal should recur without issue.

@Ejegg. I will confirm but Adyen said this: Adyen can set an automatic capture delay to make the capture on our payments immediately (or at a fixed internal like 1 or 2 days after the payments). This will affect all future payments, but the existing payment still in the Authorised state will need to be captured via calls to Adyen’s /capture endpoint or via our batch capture process job. Do you want me to have them setup a standing 1-2 days fixed settlement interval from here on out? If they can't settle the pending items, maybe I can do these manually in the console? What do you think?

@DStrine. I believe we can close this task. There is no issue with PAN at the present time. As Michael B. reports, there is a general objection related to providing the PAN which we can't do anything about, but this task, as entered above, has not recurred in the latest 2020 tests.

Hi David, we did not see PAN issues in the latest tests. This Phab tas was
opened last year in initial tests. We did not see this PAN issue in the
last two recent tests.

@Ejegg Thanks Elliot, when we call the tokens are fed into the new API and create new records, will that invoke a Thank You page? If so, can we suppress it to avoid confusion?

This is correct, Adyen don’t offer Apple Pay via HPP so it would require a checkout integration. Should we therefore close this task?

yes, there is. Let me forward that.

@DStrine I just sent the thread and included FR Tech. It is directed to LeAllyson at Ingenico. She is the one telling me the error has to do with our API. Please let me know what more you need.

Please note: I see this error increasing to 4-5% of declines in Sweden.

Hello,
I have been working with Ingenico and DS on some of the questions around this migration. Notes here:

Hi all,
I am seeing a number of orphan's NOT rectified during the Sweden campaign. This is ala the Big English trend I spotted above. I am reopenning this as I suggest it's worth revisiting this before BE2020 as this problem scales with volume and impacts valid donors. Recent examples from Sweden in the last few days:

David and I had a call with Paypal yesterday. The goal of the call was to understand what our options are to enable recurring with Paypal. Elliott, I know you/FR Tech have looked into this in the past but I thought a refresh might be good given our goals for recurring. You can see the thread below re my exchanges with Paypal which recaps the discussion. From what I understand:

Minfraud documentation on these changes here: https://dev.maxmind.com/minfraud/

1.13 . Donor services updates that there is no repeat of this issue. Could this be resolved?

@mbeattie Paypal supressed these emails and there should no longer be an issue. Donor Services should confirm.

@Ejegg . This seems to be resolved. Civi seems to be matching the DLocal portal now. I was able to reconcile November and December. Thank you!

For V2, Ingenico has specs available, from the below link you will find a list of fields and sampler requests. The good news is that the hosted page automatically ensures you’re ready for V2, as Ingenico capture all the minimum required fields from the hosted page. Once part of this though is the cardholder name, so when we are ready for V2 we will need to revisit the suppression of that field (see issue that arose on 3DS1.0 under phab task 263332). Otherwise the transactions won’t qualify and will process as V1 3DS.
https://epayments.developer-ingenico.com/best-practices/services/3dsv2/mycheckout/
There are tons of additional fields beyond the minimum ones, but Ingenico does not expect issuers to make use of all the fields for some time so we wouldn’t get much value from additional engineering.

To be clear on this. This is still occurring but it has significantly
reduced and is manageable. It would be good to resolve for next peak if
possible.

Ok, i wanted your blessing here so glad to hear you agree. I still would
like PP to troubleshoot what goes on in this scenario that causes the
duplicates so we can have messaging for incomplete transactions. The
question is why do completed transactions get the message!

After much deliberation with Paypal, and challenging that these are spoof emails by some fraudster, they have acknowledged that these emails are indeed generated by their systems. Today, 12.19, they advise they can shut off these emails and I have given the go ahead to shut these off to avoid further duplicate Paypal donations. Monitoring from here to see if this resolves the matter or if there are other impacts from shutting off the email on reattempts by donors.

Ingenico advises that this change will be deployed mid January 2020 now.

current examples are far fewer as of 12.10 volume which was reduced only 3 out of 68 stopped transactions:74887627.1,
as of 12.11 I am seeing 7 out of 70 orphans not rectified. I'll close this per our stand up today that this seems to be volume related and maybe we can just run the orphan rectifier more often during peak periods?

No, I only saw 3 orphans today out of 68 which I notated in the task. As
the volume is lowering, so are the orphans. I like your idea of running
the rectifier more during high volume events.

Elliott, I was thinking about this....I am actively settling some of these
orphans to try to recover them, along with some of the legitimate 600's
stopped for fraud. Am I clouding the picture for you at all while you try
to diagnose this? I've settled dozens in the last week.

According to Ingenico the auth on refund will not impact us (closing task).
Matthew Dale
4:08 PM (11 minutes ago)
to Jerry, me, Loida

I just pulled the fraud results for yesterday . 12.9 and just wanted to say that the scrambling referred to above is down to a handful of results out of order from the Fredge query. I am wondering if this could have been volume related? The scrambling seemed to be at its worst while we were at peak volumes, but reducing as our volumes are..... I can live with what I've got now... so less of a priority.

Current examples from 12.8
74199693.1
74198321.2
74177728.1
74012707.2
74011082.1
73779706.1
73778693.1
73778875.1
73777604.1

@Ejegg
More examples from yesterday to chew on:
73514644.1 US USD 5.35 12/5/19 17:30
73515520.2 US USD 5.35 12/5/19 17:29
73513909.1 GB GBP 10.4 12/5/19 17:25
73513825.1 US USD 20.8 12/5/19 17:23
73513305.1 US USD 17.01 12/5/19 17:21
73511980.1 US USD 10.4 12/5/19 17:18
73510741.1 US USD 52 12/5/19 17:14
73508868.2 US USD 3.1 12/5/19 17:12
73508578.2 CA CAD 20.8 12/5/19 17:09

Hi Elliott, The examples I sent were from yesterday so definitely longer
than 2 hours delayed.

Yes, sorry for leaving that off.

More of these 600's appearing in the fraud search today 12.5: 73517561.1
73485102.1
73484895.1
73484088.1
73516052.3
73481987.1
73480663.1
73515520.2
73514644.1
73513909.1

I see....I'm settling those caught where I can but the volumes are getting
too big to capture all of those at 0 any longer...that's a good tidbit to
know that it may be indicative of an API error. Learn something new every
day around here. Thanks

I pulled them out of Ingenico's console where I search for anything with a
status 600, usually from the prior day to give things time to settle.
Oddly, I haven't seen these unscored transactions appear previous to
12.2.2019....?

Hi, I put a few in the Phab task earlier. Please let me know if you need
more. https://phabricator.wikimedia.org/T239769

In many cases they are missing more than minfraud. Also missing our
checks. See examples. Thanks for looking at this.

Some recent examples from 12/4: 73143616.1, 73137282.1, 73091579.1, 73080482.1,73080991.1,73070725.1,73073754.1. Issue started on 12/2.

I submitted to PP and PP Spoof department for review. They advised that they directly reached out directly to prior donors who fell prey to this, to what end, I am yet unclear.

@Ejegg It is feasible for the main account to be used for central clearing/settlement/fundng as the integration and bank are attached. Once the accounts are created , we can set them to automatically clear out funds to the master account at a daily basis. The transactions are still related to the sub account, but the full amount is transferred in a lump sum, and not on a transaction by transaction basis. Once those funds are transferred, the master account can then automatically withdraw funds the same as it is doing today.

Paypal further explains: You would need to have two separate PayPal accounts because pricing is done on the account level not on a per transaction level. So we would need to integrate 2 separate flows, one for the <$6 goes to account A and >$6 goes to account B. We would not be able to have the flows mix. However, I want to clarify the terminology we are all using:

Dylan Kozlowski
10:28 AM (20 minutes ago)
to Merchant, mdwise@paypal.com, eeggleston@wikimedia.org, fr-tech@wikimedia.org, me, mbeattie@wikimedia.org

I shall resurrect the previous thread on this topic so we loop in the
engineer we had a call with on this subject,Dylan.

11.14 . A further update on this task is the following:

Evelyn Martin
Fri, Nov 8, 3:22 PM (4 days ago)
Hi Elliott, I put in a phab ticket for this to keep track of it. Turns out Ingenico doesn't support VPAY and know nothing about it. It's only for Adyen. Do you

This task has been moved to Phab tasks:
T236506
T230064

Civi is lower in count but higher in amount, as follows:

@Ejegg Thanks Elliott, the numbers are definitely within the realm now. Things definitely moved from 60% off to 4% off. With the changes Dlocal is proposing in a separate task, all should come into alignment now. Thanks. We can close this one!

Excellent. Do you need anything from Dlocal to troubleshoot resolution here?

perfect. Thanks!

Yes. Good idea. I agree, this is frustrating. I would agree with your proposed approach for sure.

@MBeat33 Paypal is suggesting that the above email is fraud and a spoof and have asked that we direct donors to spoof@paypal.com. They will receive a response from them with more information. Paypal maintains that they did not orginate these emails to our donors.

Paypal responded to say that they were confused and that their previous response (above) was not in relation to this issue.
" am sorry for the confusion. I got a few contacts that day showing that IPN was missing which has caused the payment not showing on user's shopping cart order management which could have triggered the shopping cart to request the customer to complete the shopping cart purchase. However, your issue was stating that PayPal was the one who sent this message to request your user to make donation. It's never PayPal's position to do so. therefore I overlooked that piece of information. and I checked your transactions. All IPNs associated with the specifics transactions were sent out promptly. Therefore it was not an issue associated with the tech issue I have stated in the previous email. I am sorry about the confusion. "

Paypal responded to say that they were confused and that their previous
response was not in relation to this issue.
*" am sorry for the confusion. I got a few contacts that day showing that
IPN was missing which has caused the payment not showing on user's shopping
cart order management which could have triggered the shopping cart to
request the customer to complete the shopping cart purchase. However, your
issue was stating that PayPal was the one who sent this message to request
your user to make donation. It's never PayPal's position to do so.
therefore I overlooked that piece of information. and I checked your
transactions. All IPNs associated with the specifics transactions were sent
out promptly. Therefore it was not an issue associated with the tech issue
I have stated in the previous email. I am sorry about the confusion. "*