Many such "helpful" widgets are often loaded using direct cross-site
<script> tags, this is a real do not do until you have established the legal liability matter clearly. As usually all liability rests with the card processing entity (the web merchant or card processing gateway) not with the widget author entity.
Another strategy is to request such widget authors provide a download ZIP of static data that can be audited/checked by the merchant or PCI card processing gateway technical engineers for possible problems and evil activity. Then this static version of the widget is served up from the merchant's own system. This of course means getting it updated is a pain for the widget author since they need to ensure long backwards compatibility or risk customer annoyance. Since often it will never be updated by the merchant that would required expensive web development skills.
Another strategy is for the widget author to provide a real supported API which the e-commerce merchant can interact with the widget authors system using controlled code. This would be similar to the static JS but handled server side. Widget authors stay away from this solution as it is usually a too expensive option for merchants to adopt the widget, compared to the lazy adding a
<script> tag and loading cross-site.
The alternative is usually much easier, to simply not use such a widget and save yourself from the risk.
To explain the attack vector it is possible for evil widget author's hosting system to serve up different versions of the JS to different users, maybe using Referrer header, randomness, country, time-of-day, etc... So one in 10000 hits gets the evil version of the JS code. But all casual inspection appears to serve up the correct good version of JS code.
Like all JS code, the evil version of the JS can read all form data fields during the submit process by attaching itself to the forms of the page. All data (including CVV/CSC, address info as well as usual card data) that is on the form is then relayed to more than one website when the unaware customer (there will be no alerts or warnings) performs the submit action. The data is then copied to both the site it should be going to (the merchant or PCI card processing gateway) as well as the evil site collecting data for evil purposes.
IFRAMEs are also not perfectly safe encapsulation mechanisms, problem have existed in the past that permitted things that should not possible to be circumvented by evil JS code. Not everyone updates their browser.
No amount of yes we have "secure" procedures double-speak from "helpful" widget authors is going to assist the PCI compliant entity when a problem occurs; and don't be fooled otherwise.
I have personally brought it to the attention of at least two UK operated PCI compliant card processors of their direct
<script> third-party cross site elements on pages presenting or receiving security (username / password) or card holder data. The problem for them is that it just isn't worth the risk to their business and bad publicity as a result of a breach due to incompetence.
These things come to your attention very quickly when you provide a secure system and network for your merchant accounting department to access payment data but only allow internet connectivity via firewall/proxy with white-list access only to the specific systems they expect to use, it is amazing how much stuff breaks that shouldn't.
Asking for an example of a breach is fruitless, no one advertises such as thing.
Hypothetical technical fix (or rant depending on your viewpoint)
What HTML really needs is the ability for the original origin server to provide one or more checksums (MD5/SHA1/etc) and length information of the target script. This way it is possible to the consuming website to have complete control over the exact copy that the browser will accept from the serving website.
<script src="http://mostly.trusted-site.com/useful-script.js" security:checksum="md5:0123456789abcedf;sha1:0123456789abcdef0123;length:543" security:options="load-from-cache-from-anywhere-matching-checksum;no-send-referrer-header;no-use-cookies;no-use-etag;high-security"></script>
This script tag is hypothetical (do not use) but where HTML needs to move towards. It serves to illustrate a potential future HTML5+ fix in the problem domain.
Now the target site can not change the content from under us, they get to see the hits and serve the content. Multiple parties across the internet would independently audit the same code allowing many eyes of peer review of the same JS code for evil things, as you can build trust around checksum values.
Multiple hashes are allowed to support overlapping migration to more secure/longer/widely-supported hashes, also reduces theoretical chance of collision.
Allow loading from cache from any alternative website that has same checksum matches (allowing for zero-hit CDNs which are the fastest CDNs you can get, finally you get to go back to your server again). Since you can have your own local copy of jquery.js but allow the client browser to satisfy the script completely from cache when if loaded from another website. Since for most users there will never be any hit for jquery.js on any server (not even to revalidate) as it will resolve from cache.
Get to control what identifiable information the clients browser will send by default when accessing the URL to download the script. You can hit it without Referrer header, never sending or storing any cookies, same with ETag, etc.. I illustrate the use of "no-" implying a default of these things being allowed, the default should be the reverse, all things inhibited unless allowed. The "no-" is to illustrate the kind of information control the consuming website can obtain.
Until this happens simply copy the JS into your website (after you audit it)