We as a PSP register merchantIdentifiers when registering merchants to ApplePay.
We then use these identifiers in a multiTokenContexts during ApplePay session creation / validation / payment.
"multiTokenContexts": [ { "merchantIdentifier": "ABC-MID-1", "externalIdentifier": "MAIN_PURCHASE", "merchantName": "Main", "amount": "2.50" }, { "merchantIdentifier": "ABC-MID-1", "externalIdentifier": "CONVENIENCE_FEE", "merchantName": "Fee Processing", "merchantDomain": "m2.example.com", "amount": "2.50" } ]
in response we get
"authenticationResponses": [ { "merchantIdentifier": "0aff534d6d46fd653f60e6161c53101ee8d9cbc20b1bc40533c929d0a6aae6bc", "authenticationData": "AAAIAKnglVRsCyOvcgI*=", "transactionAmount": "250" }, { "merchantIdentifier": "bfc9a63b4ebab8cde90234731cb18a544c306b0af747d93d773fedb603f0945e", "authenticationData": "AAAIANBEqODkDcrDTgI*=", "transactionAmount": "250" } ]
We need to know how to match the entries in the request array to the response array. Is the order guarantied?
We did not find any documentation on how the response hash for the identifier is computed.
Hi @KarolSladecek,
You wrote:
We need to know how to match the entries in the request array to the response array. Is the order guarantied? [...]
No, the order isn't guaranteed and you shouldn't rely on positional matching. There is no documented ordering guarantee for authenticationResponses. While in practice, the order often mirrors your multiTokenContexts requests array, this is an implementation detail, and not a contract. Apple can change server-side behavior (for example, parallelizing token issuance) without it constituting a breaking API change, if ordering was never formally guaranteed.
That said, the risk of positional matching is severe: a silently mis-ordered response would route the wrong payment token to the wrong merchant context without any error signal.
For more details, see the documentation below:
Payment token format reference
https://developer.apple.com/documentation/passkit/payment-token-format-reference
Then, you wrote:
We did not find any documentation on how the response hash for the identifier is computed. [...]
The response's merchant identifier hash is a SHA-256 of the raw UTF-8 bytes of the plain merchantIdentifier string. This is consistent across Apple Pay, as the same SHA-256 hash appears in Payment Processing Certificates as well as for some fields used for ECC token decryption.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
