Confirming that I do indeed use the Gateway recon report. Please do not delete. Thank you:

Hello, Paypal is telling me that this rule went into effect today. FRTech, can you see if those payments under $1 are being denied. Additionally the main concern was the stopping of payments. Paypal is not seeing any being stopped.

Hi Folks Paypal has come back to advise that the Braintree connection is their promoted option for enterprise accounts such as Wikimedia so it looks like we do not need to consider a direct connection on a reintegration and Braintree is the path forward. Notating this here for reference when we get to prioritizing Paypal.

Adyen came back to explain that Pay-by- Link won't work for us so the Drop in solution would be the way to go if we upgrade:
Hey Evelyn,

Thanks Michael, Amazon is investigating but no update as yet! I am
pressing them.

@DStrine I've looped Amazon in and they report: "We don’t have any reports of an outage yesterday." I sent them some screen shots from DS zen desk tickets to see if they can garner anything from that. Meanwhile, Amazon settled proceeds were higher yesterday by ~25% than the prior day so it doesn't seem to be a widespread issue. I'll update here if I get more from Amazon.

I have inquired with Amazon to see if they experienced any issues yesterday.

Putting this piece of info here follow up a call that DS and Elliott had with Adyen since it is impactful to our consideration on which upgrade approach to take:

I just heard back from Paypal. The rules team advise that it looks like option #2 is being implemented on December 17th with the expectation of going live on December 20th. They are in the middle of a moratorium through the end of the year, which is why there is a little bit of a delay, but I will confirm with the rules teams on the go live date along when it is implemented and update here.

Thanks David! I'll let them know and ask them to confirm they've done it
and update the case.

Status as of 12.4.2020 7am PT: From Ingenico: “Connection issues for some merchants to Miami. We are experiencing issues with the Internet Service Provider in Miami Datacenter. Currently we are processing in AMS datacenter (switched at 19:35 hrs. Dec 3rd) 2020-12-04 07:00 – Traffic was switched to Amsterdam on 19:35 (Dec 3rd). As there currently is no merchant impact, it was decided to leave traffic pointing to AMS until normal working hours to give the Service Provider time to work on the fault.”

see task: https://phabricator.wikimedia.org/T269378

Ingenic has routed us out of their Miaimi data center they report an issue with their Internet Service Provider there. We are monitoring issues with DS to see if this quiets things down.

Ingenico is having an intermittent problem today and it is being triaged.

@MBeat33 I was on the phone with Ingenico and they acknowledge they have an issue in flight right now. Donors may experience a timeout or SLL error and it would be impacting the console as well. They will advise when they have diagnosed the problem. It appears intermittent but it is being reported by several merchants. I have shared your examples above as well. Thanks

@MBeat33 Update: I had Ingenico look into this timeout and they report:

Hello, I am putting the current specs for Paypal here given this task is active per David's request:

This was due to maintenance and is resolved now.

Thanks for the update, Dallas and Christine!

Do you have merchant reference number associated with these by any chance?

I will look into this and get back to you.

Some added insight from Ingenico about their Apple pay support when we are ready : We do support the native in-app integrations, sorry for not confirming earlier. We can set this up in the pre-production environment for your team to start working on, and I’ve copied Jerry and our colleague Dianna, who is working through this with another customer of ours. We are working through a few minor bugs over the next few weeks but it is ready enough for you to start working on. I would suggest we start with one currency, say USD, just to keep the scope narrow to begin with, is that okay with you? We do support all and can add more, but I think it may be clearer to add them once we have successful USD tests going.

From Ingenico who have looked at the API calls on their end: the error is not being received as a result of an incorrect setting or anything wrong on our end.

More from Ingenico: Unfortunately Jerry looked into the option of you passing it to us and it won’t be possible as that field isn’t available in the hosted checkout. Sorry for the mis-direction, I was trying to think outside the box. We can keep it suppressed as it is now, but as that field is required for V2 it will mean all 3DS transactions will fall back to V1.

More from Ingenico on this one: The 'CardHolderName' is not included in the 'GET_HOSTEDCHECKOUT' API response. Ingenico's other merchants seem to be okay if they have to capture the consumer’s name twice. One option could be to pass our name fields (concatenated) into the cardHolderName field in the hosted checkout request. Is that something we think would work?

I will check. I've also asked how other merchants are coping without the
name field. We can't be the only ones who need it....

Hi All, I checked back in with Ingenico on the name field for 2.0 to see if they could take what we passed them. From Ingenico:
We are assessing the possibility of using the first and last name you provide in place of cardholder name, but I do not think that will happen this year. We did not build it that way because per the EMVCo (card brand org) specifications the cardholder name is a very specific field with specific format restrictions, and our team thought it was best to implement the field distinctly. We have also done data analysis which seems to show that in most cases customers do not enter in the same cardholder name as billing first and surname. Beyond cardholder name, everything else is already captured from the HPP, so indeed no work needed from Wiki to support 2.0. Its not even configuration, all our HPP merchants are automatically set up to support 2.0.

I just played with the form and it is running with expected results. Both Ingenico and Adyen have a 'load' time which is known. I am asking for an hour glass spinner to indicate loading but so far have not been successful. Ingenico reports they may look at this next year (2021) but keeping expectations low.

I’d say close it John. If we ever go big with Adyen we may want to revisit but I don’t see that in the cards at the moment.

Correct, not high. 6ENC last year didn't register much JCB and annually it
represents <2% of volume overall.

Ingenico is asking for: If we can get the full XML for both API's that would be great. We're aware that you're using Connect -Hosted Merchant Link, but we want to compare the APIs with the format on the Developer portal.

of course. Thanks!

Hi, the DS team continues to see these declines and they still come up in our decline reports. I had another run at talking to Ingenico about them and cited what Elliott mentioned above in that this Invalid Pares error occurs outside of our jurisdiction within the transaction. Ingenico came back with:

Hi all, please note this updated ApplePay spec from Ingenico: We have very recently published new technical content that your team can start to review, see below and please let us know if you have any questions. Happy to schedule a call to review in depth as well. We are close to being able to open up the pre-production environment, we’ll be sure to let you know as soon as we have a concrete date for that.

Not material from my perspective.

Leticia has been added, Dallas

Dallas, approval is in the task. I will forward you the email from Lisa as
well.

The recent prior one was for Dlocal in case we are thinking this is the
same thing. Didn't want us to overlook this Ingenico one if we are
confusing with Dlcoal. Coincidentally, they are coming up a the same time.

We are already using the new certificate so all is well per Dallas. Closing case.

great! thanks

Hi All, adding some additional info here for future consideration. MC is going to announce that they will end of life 3DS1.0 in 4.2022 and they are increasing costs associated with 1.0 to incentivize the move to 2.2. Visa announced something similar but I don't have their date. 3DS upgrade should be on our roadmap therefore for next calendar year. I have reached out to Ingenico to resurrect the topic of the name field and what we can do to retain collecting the name on our end. Just notating this here and I will raise with Pats to prioritize with FrTech when the time is right.

NZ = CC (Visa, MC, AMEX) and Paypal
AU = CC (Visa, MC, Amex, JCB) and Paypal

Most recent screen shot I got:

Hi All,

I just tested it and it looks great! Thank you FRTech!

Ok. I'll give it a quick run through once it is deployed.

Looks great and vastly improved! Can I test before we put it live?

Hi all, thanks for your attention here. We worked out his access. Thanks so much for the help. Closing this task!

Hi Elliott, I think I got confused with what Dallas sent me. The link he
sent me went here:

Hi Dallas, We need to pull specific merchant reference numbers out of Civi that bear a status of 600/stopped. Tomas needs to upload the merchant reference numbers of all stopped transactions and pull these out of civi. We just tried the query in Civi in the link above and set the date range to 9.2.2020 and got back every transaction for yesterday. Can he be granted the upload capability that I have? thanks so much!

Results for India in moving to 75INR vs 150
Big end-of-campaign test win for 75 INR minimum (control is 150) -- All sizes won!
Desktop large: 52% lift! | Desktop small: 57% lift | Mobile large: 52% lift! | Mobile small: 84%!!!

I added him to the list. He is not a FT employee of Fundraising but
helping out from another department. Not sure if that's relevant or not.

Hi, I am noting it here that CVV is not a mandated field through Ingenico's payment page. We can mandate it as a required field, at our option, but it is not setup that way today per our account team. Looking at CVV usage, most issuers in the English speaking countries we fundraise in are declining if CVV is not present but not all. We discussed today to leave our form as is without mandating that the field is populated.

Pats indicated we can lower it now for India and raise it again after India on 8/26/20.

yes, thank you @Elliott Eggleston <ejegg@wikimedia.org> !!

Hi all, we have a meeting with Dlocal in the morning to discuss this. Would it be easier if someone from FRTech joined that call perhaps? 8:00am PT. Thurs August 6.

Thank you! I will let Paytm know.

@AndyRussG. Yes! It's great! I am forever in your gratitude. I really
appreciate this change.

I looked through the ZenDesk tickets that DS has shared. I observe:

I can ask them for an SVG. They didn't provide that. They sent the logos
attached to the task. That's all I have.

Trying to piece together other examples. DS is stating the issue is growing.

Seilo in JP was able to get to the TY page in a test transaction or two today.

I obtained further clarification from paytm about the difference in the recent logo:
Hi Evelyn,

Hi All, I had Sielo test a transaction on donate wiki in JP. He was able to get a TY page: https://donate.wikipedia.org/w/index.php?title=Thank_You&country=JP

Hi - I heard back from Dlocal today. They had this to say "Regarding Amex, I double checked the logs and I'm not seeing anything weird. You had a lot of cases in which the user entered the wrong cvv but I'm not seeing anything wrong regarding our connection with the acquirer."

Thank you!

Hi all, I am in favor of just disabling AMEX for the India campaign. It is insignificant (less than 1%) for this market and low approval rates seem to be a previous trend. @FR-Tech. what would be involved with disabling AMEX entirely?

I wanted to note here that AMEX was less than 1% of prior test volumes. It also had low approval rates at 13% in prior tests. The behavior may be typical of AMEX in India.

Here is the AMEX transaction that cleared. Looking back at the prior
campaign test, I see that only 27 out of 167 AMEX transactions got
approved. This could be an issuer denial thing.

Why is it that I see that Praveen cleared an AMEX transaction yesterday: 81380244.2?
Are we certain he didn't hit a velocity filter?
Dlocal is saying it is working ok but they are checking with their in-country (india) team

Thank you Sam and Peter!

Important input here from Dlocal Operations + Fraud team: you will need to have that field in your FrontEnd and if the user inputs it you will need to send it, you will ONLY be sending the fixed one if the user didn't complete the field.

Great. Thank you!

YAY!!

Great Christine. Looking forward to converting the rest !