Short version:
You seem to be A-EP You seem to be A, based on the specific products referenced, but you should ask your processor(s) to be sure.
If by "Amazon Payments JavaScript widget" you mean Amazon Express Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website".
Amazon Payments "Login and Pay" is jut a button that takes the processors site, and the entire payment is carried out on the processors site, so technically there are no "elements of the payment page (that) originate from the merchant website" - the payment page is all on Amazon, none on your site. So that should also be SAQ A, although it would be really nice if Amazon put this in their FAQ.
Mind you, the distinction between a link that sends customers to the processors site and a link that cites an iframe on the processors site and a link that uses direct post or javascript requests to send card data to the processors site are, in security terms, completely equivalent. In all cases, an attacker who compromises the merchant's web server can affect where the customer sends their card data. The only significant difference is that the customer can see the processor's URL in their address bar with something like "Login and Pay", and we assume people check that and know not to perform Amazon payments with aamazon.ru, even if it has a valid certificate.
Or - in short - if this is confusing to you, it's because it's confusing. Again, best to ask your processor. They're supposed to know better.
If by "Stripe Checkout widget" you mean Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website."
According to Stripe, even though Checkout is a JavaScript widget "it already rests inside an iframe controlled by Stripe, you can continue to fill out SAQ A." (emphasis mine)
You would only seem to be SAQ A because all your checkout forms were hosted by the processors and your customers were directed to them before checkout or via an iframe .
Long version:
The key distinction here is found in page iii of the SAQ A:
The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)
If your processors all get invoked via an iframe, then you probably meet this requirement. But if their "javascript widget" or "checkout widget" are served from your servers, then you fall into SAQ A-EP instead. Your processors, of course, should be able to tell which they are.
The fact that the word "Javascript widget" shows up here suggests to me you're A-EP, but I'm not familiar enough with Amazon or Stripe's offerings to really know. And, honestly, you're not really expected to know the difference - they are.
The full set of expectations for a SAQ A merchant to meet are as follows:
SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.
SAQ A merchants confirm that, for this payment channel:
- Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
- All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
- Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
- Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely
on a third party(s) to handle all these functions;
- Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder
data are PCI DSS compliant; and
- Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
Additionally, for e-commerce channels:
- The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated
service provider(s).