How to test apple pay in app?... When i implement Apple pay then how can i test?

I'm eager to learn more about off-session payments and pre-authorization procedures facilitated by Apple Pay. To begin, could you kindly clarify whether Apple Pay offers the capability to initially authorize an amount and subsequently finalize the payment at a later point? Additionally, I'm curious if it's possible to execute off-session payments using the Apple Pay platform. Your insights on these matters would be greatly appreciated.

Hi there, we are currently implementing Apple Pay and we have quite some issues in testing Apple Pay. As Austria isn't on the list of countries where Sandbox Testing is supported, as mentioned on https://developer.apple.com/apple-pay/sandbox-testing/ Is there any other way we can test In-App Provisioning and other use cases? Thanks a lot for helping out.

After replacing the new certificate, we have adjusted the TLS version and SSL encryption algorithm, upgraded the API of the endpoint, and reviewed the related Apple Pay documents and demos based on the Develop Account. However, we still verified that the domain name of Apple Pay cannot be connected. Exceptions: API calling about Apple Pay $ java -version java version"1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java Hotspot(tm) 64-Bit Server w (build 25.201-b09, mixed mode) Apple Pay Backend setting TLS version：jdk 1.8 The default version is SSLv1.2; also supports 1.1，3 SSL encryption algorithm： defaultCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 supportedCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 Certificate used Other setting related： JVM parameters -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=path_to_file\\apple_pay_qa-202306052251.p12 -Djavax.net.ssl.keyStorePassword=**** Multiple approaches tried and the corresponding result After replacing the certificate，it shows Connection reset；Received fatal alert: handshake_failure Suspected this is related to TLS version issue，after specify TLS version to 1.2, still receive the above error After checking with Apple document, found that there is a suggestion to use the new API, but the error still persists after trying Requesting an Apple Pay Payment Session | Apple Developer Documentation We have also tried with other HTTP Client (Spring RestTemplate, Apache HttpClient) request methods, but still got similar errors Demo Code

We are trying to implement Apple pay support for our application and we're unsure of whether we should implement Apple Pay Merchant / In App Purchasing. (as an in app capability) Here is an executive summary of our use cases. -The app acts as a store front that matches popular content creators and users. -Members can pay and request content creators to make a video (happy birthday for example). Creators will make a response and send this to the user directly through the app. -Members can pay to send content creators direct messages So the app acts as sort of a marketplace, but the exchanged good even though it is tangible (a video you can re-share), isn't physical. Our app takes an X% cut, then pays the content creator. So we aren't sure whether this qualifies as an in app purchase or not from a technical standpoint, or whether we can just implement apple pay transactions. Happy to do either one, just don't want to go down the wrong path and then get the app rejected.

Hello, all. Development environment: xcode14.3 + iOS16.4 + iphone12 mini When I use multiTokenContexts to complete the multi-merchant payment function, it prompts "Try Different Payment Method". But if I just perform the payment function of a single order, the payment process can be completed normally. So I would like to ask, is there any limitation to use multiTokenContexts? Thank you, looking forward to your reply.

Hi, Im newly to Apple Pay and I have some questions: Backend Integration Documents: I can not find the backend documents :( Authorized Token Duration: When user authorize the pay request, the merchant'll provide a authorize token. So how long does it last for? Purchase Authorization and Delayed Processing: Our platform involves a scenario where users initiate a purchase, but the actual processing of the payment occurs at a later stage after an administrator approves the request. Is it possible to utilize Apple Pay in such a manner, where the user's authorization is retained by our backend system until the payment is approved and processed? Refund Functionality and Fee: Does Apple Pay offer a built-in refund function for transactions? If so, could you provide details regarding the refund process and any associated fees? Please help, Thank you

Hi, I'm trying to create merchant tokens in ApplePay sandbox environment, so then I can use them to invalidate token API call and lifecycle notifications testing. When processing test payment I use Apple Pay payment request taken directly from Apple's demo website (I skipped non important part of JSON) { ... "recurringPaymentRequest": { "paymentDescription": "A description of the recurring payment to display to the user in the payment sheet.", "regularBilling": { "label": "Recurring", "amount": "4.99", "paymentTiming": "recurring", "recurringPaymentStartDate": "2023-08-11T11:20:32.369Z" }, "trialBilling": { "label": "7 Day Trial", "amount": "0.00", "paymentTiming": "recurring", "recurringPaymentEndDate": "2023-08-11T11:20:32.369Z" }, "billingAgreement": "A localized billing agreement displayed to the user in the payment sheet prior to the payment authorization.", "managementURL": "https://applepaydemo.apple.com", "tokenNotificationURL": "https://applepaydemo.apple.com" }, ... } Payment is successful, but merchantTokenIdentifier in decrypted ApplePay token is always empty, regardless of test card used, I tried Visa, MasterCard, Amex. Anyone have an idea what I'm missing and how to get that merchant token? Is it even possible to test merchant tokens (lifecycle notifications) in sandbox?

Last month our certificate key expired for Apple Pay, For generating new certificate Followed this document TN3103: Apple Pay on the Web troubleshooting guide | Apple Developer Documentation ) My payment service provider created certificate signing request (CSR).(Not provided key) Uploaded this CSR to the Merchant Configuration page to generate a Payment Processing Certificate Downloaded payment processing certificate Downloaded Merchant Identity Certificate Both certificated installed in key chain, But the key file is not found so can't create Certificate.key.pem ` public function apple_pay_session(Request $request) { $certificatePassphrase = ""; $merchantIdentifier = "merchant.name.com"; $displayName = "merchant name"; $initiative = "web"; $initiativeContext = "www.merchant.co.uk"; $certPass = ""; $certFile = public_path('merchant_id.pem'); $keyFile = public_path('Certificate.key.pem'); $data = '{"merchantIdentifier":"'.$merchantIdentifier.'","displayName":"'.$displayName.'","initiative":"'.$initiative.'","initiativeContext":"'.$initiativeContext.'"}'; try { $ch1 = curl_init(); Storage::put('computop_applpay_try_session_'.time().'.txt', "In session"); // Check if initialization had gone wrong* if ($ch1 === false) { throw new Exception('failed to initialize'); } curl_setopt($ch1, CURLOPT_URL, $request->validationUrl); curl_setopt($ch1, CURLOPT_SSLCERT, $certFile); curl_setopt($ch1, CURLOPT_SSLKEY, $keyFile); curl_setopt($ch1, CURLOPT_SSLKEYPASSWD, $certPass); curl_setopt($ch1, CURLOPT_POST, 1); curl_setopt($ch1, CURLOPT_POSTFIELDS,$data); curl_setopt($ch1, CURLOPT_RETURNTRANSFER, 1); $merchantSession = curl_exec($ch1); // Check the return value of curl_exec(), too if ($merchantSession === false) { throw new Exception(curl_error($ch1), curl_errno($ch1)); } return response()->json([ "merchantSession"=>$merchantSession, "certFile" => $certFile ]); } catch(Exception $e) { Storage::put('computop_applpay_catch_session_'.time().'.txt', $e->getMessage()); return response()->json([ "code"=>$e->getCode(), "msg" => $e->getMessage() ]); } }` We only have apple_pay.cer ,merchant_id.cer, certificate signing request (CSR) provide by the payment service provider." How to create merchant_id.pem,Certificate.key.pem from It..? Or is it possible to do payment validation in PHP without these files?

I am working on a banking application (includes iPhone and iPad) which includes add to wallet feature. During the implementation I saw one document it is mentioned that for iPad app, the app must be extended to support Apple pay functionality. Details from document says "Card Issuers with an iOS mobile banking app must support Card Issuer iOS Wallet extension functionality to enable Card issuer mobile app customers to provision new cards directly from the iOS Wallet app with all eligible Apple iOS devices. If the Card Issuer has a dedicated iPad App, that App must be extended to support Apple Pay functionality. " Is wallet extension implementation required for Apple pay to work in iPhone and iPad? Is wallet extension a mandatory implementation for Add to Apple Wallet feature to work and approved by Apple? I am little confused in this. Anyone who integrated Apple pay or done add to Apple Wallet feature recently without wallet extension faced any rejection? Any help would be much appreciated.

I have a iOS application that provides virtual sessions on mental health. In order to book a session i need a payment gateway to get paid. Please provide me A CONFIRMATION if i can use apple pay directly via stripe to do the same. Also if someone suggest IAP for this then the final amount will be custom amount which not comes under any Tier which IAP provides. can you please provide solution on this complete cases.

I am developing an iOS application that involves online payments. I am using the Apple Pay API to handle the payment process, but I encountered an issue where I receive two callbacks after the user initiates a payment: one synchronous and one asynchronous callback. This has resulted in the generation of two separate orders, and the user is charged twice. The transaction receipts contain identical data, except for the platform order number. I have contacted Apple Developer Support, and they confirmed that both callbacks represent successfully paid orders. Has anyone encountered a similar issue, and if so, are there any solutions or suggestions to resolve this problem? Thank you!

On simulator, everything works fine. But when I run on an iOS beta 3 device, the UI simply doesn't change. I just see the one button stay there. Logs show the below upon every click. I know there's the expected System UI with "Hold here to present" based on the simulator, but I can't see it on a real device. Is there some Terms & Conditions thing I should expect, maybe? Please advise. Thanks. . . . [for reference, the below are the error logs in Xcode] An error occurred while reading a mobile document: The operation couldn’t be completed. (ProximityReader.MobileDocumentReaderError error 6.) serviceUnavailable Could not create identity session due to: [ Error Domain=ProximityReader.IdentityReaderErrorInternal Code=15 UserInfo={NSDebugDescription=, code=} ]

I am coding for Apple Pay in-App provisioning extension, but there was a problem when Apple Wallet load authorization UI extension: The source code: The principal class .h file #import <UIKit/UIKit.h> NS_ASSUME_NONNULL_BEGIN @interface IssuerProvisioningViewController : UIViewController @end NS_ASSUME_NONNULL_END The principal class .m file #import "IssuerProvisioningViewController.h" #import <PassKit/PassKit.h> @interface IssuerProvisioningViewController ()<PKIssuerProvisioningExtensionAuthorizationProviding> @end @implementation IssuerProvisioningViewController @synthesize completionHandler; - (instancetype)init { NSLog(@"--- init"); self = [super init]; return self; } - (instancetype)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { NSLog(@"--- initWithNibName nibNameOrNil"); self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]; return self; } - (void)viewDidLoad { NSLog(@"viewDidLoad"); // Do any additional setup after loading the view from its nib. } @end The Info.plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.PassKit.issuer-provisioning.authorization</string> <key>NSExtensionPrincipalClass</key> <string>IssuerProvisioningViewController</string> </dict> </dict> The entitlement file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.payment-pass-provisioning</key> <true/> </dict> </plist> Environment: iOS 16.4.1 I found the method viewDidLoad was not be called after invoking method init. Thanks for reading and any advice.

What is the List of supported Web Browsers for Apple Pay on the Web? We were able to do a PoC that starting from IOS 16 the Apple Pay works on Google Chrome, but there is no official documentationt that states about that. Is there any other official statements from apple regarding support of Apple Pay for other browsers than Safari.

I am working on Issuer Extension using which user can add debit/ credit card through wallet directly. This is Extension based (Non and UI Extension. I am nearly implemented this however have doubts about PKIssuerProvisioningExtensionHandler methods which are below open func status(completion: @escaping (PKIssuerProvisioningExtensionStatus) -> Void)  open func passEntries(completion: @escaping ([PKIssuerProvisioningExtensionPassEntry]) -> Void) open func generateAddPaymentPassRequestForPassEntryWithIdentifier(_ identifier: String, configuration: PKAddPaymentPassRequestConfiguration, certificateChain certificates: [Data], nonce: Data, nonceSignature: Data, completionHandler completion: @escaping (PKAddPaymentPassRequest?) -> Void) My query is what is the significance of configuration in last callback. Can anyone please help with this. Thanks in advance

Created merchant id and processing certificate and enabled apple pay on xcode but amount not getting debitted from account. What steps should I take ? Followed this tutorial - https://www.youtube.com/watch?v=1kRqM7F3AIQ&t=994s. Thank you.

I'm getting "Apple pay is not available for this website" error on SB after the onpaymentmethodselected event (not getting error onvalidatemerchant event) and the onPaymentAuthorised doesn't get hit at all. Here's my session data { "epochTimestamp":1652440219969, "expiresAt":1652443819969, "merchantSessionIdentifier":"SSH37EBB5A957294F0FBBD4F9C496317E1E_916523AAED1343F5BC5815E12BEE9250AFFDC1A17C46B0DE5A943F0F94927C24", "nonce":"51b5b6b1", "merchantIdentifier":"1B0FD6FCF62FBDA91A08BA2A18F4283AC1FFF6B69FC191B9F886482370BFC729", "domainName":"d176lcemp34qxj.cloudfront.net", "displayName":"Shamim", "signature":"308006092a864886f70d010702a0803080020101310f300d06096086480165030402010500308006092a864886f70d0107010000a080308203e43082038ba003020102020859d8a1bcaaf4e3cd300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303432303139333730305a170d3236303431393139333635395a30623128302606035504030c1f6563632d736d702d62726f6b65722d7369676e5f5543342d53414e44424f5831143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d030107034200048230fdabc39cf75e202c50d99b4512e637e2a901dd6cb3e0b1cd4b526798f8cf4ebde81a25a8c21e4c33ddce8e2a96c2f6afa1930345c4e87a4426ce951b1295a38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e041604140224300b9aeeed463197a4a65a299e4271821c45300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020347003044022074a1b324db4249430dd3274c5074c4808d9a1f480e3a85c5c1362566325fbca3022069369053abf50b5a52f9f6004dc58aad6c50a7d608683790e0a73ad01e4ad981308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018d30820189020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553020859d8a1bcaaf4e3cd300d06096086480165030402010500a08195301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3232303531333131313031395a302a06092a864886f70d010934311d301b300d06096086480165030402010500a10a06082a8648ce3d040302302f06092a864886f70d01090431220420463e324ef2a67be4caad2196e90cd77e4a215ee2e2dee5ebb37bc5f18d4f0e76300a06082a8648ce3d04030204483046022100b1aef11ea8f5940eef195c13d0879528ff6ddd59a671aaede8bdb0a4a0aafc290221009257a1f32bfea292d8cd819682343d840b75a1d332c3154c33b701a3b8c0166b000000000000", "operationalAnalyticsIdentifier":"Shamim:1B0FD6FCF62FBDA91A08BA2A18F4283AC1FFF6B69FC191B9F886482370BFC729", "retries":0, "pspId":"1D867D2918895F195CF99A0BCCA8B3E63C0AB3FC997F254501617482BBCF21F9" } and this is the url that i'm testing with https://d176lcemp34qxj.cloudfront.net/MerchantSiteSB.html Can somebody please assist to find the issue? or how should i get more details on the error?

I'm wanting to implement and test Apple Pay on the Web using my localhost instance. I've managed to set everything up correctly and so I'm able to get a merchant session from the Apple Pay API, but the client code immediately calls oncancel after calling session.completeMerchantValidation. After following this I'm seeing the following in the terminal: com.apple.PassKit.PaymentAuthorizationUIExtension: (PassKitCore) [com.apple.passkit:Payment] Evaluating merchant session using PROD trust policy. com.apple.PassKit.PaymentAuthorizationUIExtension: (PassKitCore) [com.apple.passkit:Payment] Application failed to provide a valid merchant session. We can't proceed to authorize the transaction. From reading various online sources, including the documentation referenced above, it seems like this might be happening because localhost isn't a validated/verified domain under our merchant account which also means using localhost seems to be out of the question for local development. I was hoping that using the sandbox account would have been enough to maybe loosen up the domain requirement, but not so. Anything that can be set either on the account or in code to allow for the use of localhost with Sandbox accounts or is there some tool that I need to use for this or is this really only test-able under our sandbox domain?

How can I access Apple Pay sandbox transaction history?