I don't have any concrete information, but... Judging by the length, it could be YYYYMMDD.

Have you taken a look at this: https://applepaydemo.apple.com/in-app-provisioning Might be what you're looking for.

What do you mean pending? Pending on Apple Pay or pending on bank? If it's the former, please check the type you're sending. Is it pending or final? For the latter, you'll need to contact your bank.

You need to contact Apple for that. The Acceptable Use Guidelines says you can not collect donations for non-profit organizations unless approved by Apple. https://developer.apple.com/apple-pay/acceptable-use-guidelines-for-websites/

Thanks @TapThatApplePay , have you been able to find a solution/workaround? I find it rather odd that we have no problems with decimal amounts for trx with USD/EUR. Just RSD.

Apple Pay doesn't seem to provide the 3DS protocol information directly. But as far as I know, this information should be returned in onlinePaymentCryptogram - but depending on the card brand, how you extract that information will differ. I would recommend talking to your payment processor, they should have the information on how to extract that information from the cryptogram. Or maybe you can ask if it's acceptable to send 2.x instead of the specific protocol version.

The $1/0 preauth would only be used to save the card in your system. The actual charge would be made once the amount is finalized. If your bank allows it, you could do a sale here directly, no need to do preauth/capture. I’d also suggest implementing future payments for declined charges. For example, if a charge fails on t, you could set up a flow that tries the same charge again on t+1. Like I said, you've gotta be careful here, Credential on File has a lot of rules and regulations and stuff you need to consider. I would definitely recommend talking to your gateway/bank/service provider before moving forward.

With card present environments, what's happening there is Apple Pay is sending the DPAN and cryptogram to the terminal, and terminal completes the charge. However, in card not present environments, from a payment processing UX perspective, the user has to see the amount they are confirming for pre-authorization. Otherwise it could lead to fraud cases. You could consider talking to your gateway or bank for Credential On File (COF) if you want to implement something similar to card present environments: You can save the card with a symbolic amount (or zero if the banks allow it) and then use the card you saved for the actual charge. But please beware that Credential On File brings its own set of rules and implementation requirements.

That could be a little problematic to have all gateways in the same domain because as far as I understand, Apple provides the domain verification files per platform integrator, so the gateway that provided you with the verification file is your integrator. And I am not sure how Apple treats multi-integrator platforms. Is it possible for you to register as a merchant, decrypt the payload as a merchant and then send the transaction to gateways for authorization? That might be a better solution.

You need to enroll as an organization if you are a registering as a PSP. You can find the guideline and requirements on the enrollment page.