All inputs created with type="tel"

[aloneartist]

All iframe input fields are created with type="tel", see:

globalpayments-js/src/ui/iframe-field/index.ts

Line 53 in b19eeb5

input.setAttribute("type", type === "button" ? "button" : "tel");

This causes issue for alphanumeric fields(like card holder name) on modern mobile devices.
User is not able to fill such fields properly, as on mobile devices such field will switch keyboard layout to "phone", allowing only numeric values to be typed in.

[slogsdon]

@aloneartist We are working on an update to address this. A short-term solution is below:

• Hide the card-holder-name iframe container
• Add a new regular input for the card holder name
  • example: <input id="cardholder-name-source">
• Adjust your JavaScript. Important changes are below:

// new variable
var cardHolderNameIframe;

cardForm.ready(function(fields) {
  // this is a new line to get a reference to the card-holder-name iframe once the form is ready
  cardHolderNameIframe = fields['card-holder-name'];
});

// this is new code to capture changes to your new card holder name input
document.getElementById("cardholder-name-source").addEventListener("input", (e) => {
  if (!cardHolderNameIframe) {
    return;
  }

  // pipe the new value to the card-holder-name iframe
  cardHolderNameIframe.setValue(e.currentTarget.value);
});

These changes should get you going and not introduce any additional PCI-DSS scope to your integration.

Please let us know if there are any questions/concerns.

[JamesB7]

How far can this go without introducing PCI-DSS issues? Is it just a question of ensuring that my server never receives the credit card information? I would very much like to make Chrome able to autofill the credit card data, but this styling can't be done with the iframe elements on their own.

[slogsdon]

@aloneartist Small update. We have the necessary changes in place to correct the input type for the card holder name. We're currently under an organization-wide code freeze, but once that's lifted, we are looking to get this change pushed out to production. We'll circle back around once it's available.

@JamesB7 While technically possible to expand the above solution for the card holder name to the card data fields (card number, expiration date, security code, and submit button), this will alter your PCI-DSS scope and compliance requirements since the card holder is no longer entering their card data into a Heartland / Global Payments controlled environment. As noted in #5, our next production deployment will allow for both PaymentRequest and credit card auto-fill from the browsers that support those.

[JamesB7]

Excellent. Around when is this expected to happen? Thanks!

[slogsdon]

Apologies for the delay. We had some unforeseen restrictions put in place internally that added time to our deployment. This has been pushed out to our production environment. The latest version is now 1.3.0 available at:

https://api2.heartlandportico.com/SecureSubmit.v1/token/gp-1.3.0/globalpayments.js