@wp wrote:
So will it at some point work the way I'm describing it? Or if not, what will be the mechanism for handling custom receipts?
At some point there will be more info passed as part of the redirect scenario. At this point, I can't tell you what that would be or how that would work. At the minimum, it's likely that the cancel and continue buttons could be configured to do a form POST, but whether there would be a separate notification fired, I don't know. A Webhook won't be guaranteed to fire within milliseconds, but then again, an Accept Hosted specific notification that's out of band probably couldn't be guaranteed to fire within milliseconds either.
Let me make it clear in case it wasn't before. A custom receipt page is currently not a supported scenario when presenting the payment form as a simple page redirect. The documentation isn't clear there, but will be clarified soon. We'd love to be able to offer that functionality, though, and providing transaction confirmation and details back to your server is obviously key to that process.
In the scenario of a custom receipt page on a redirected form, a hypothetical POST issued by the continue or cancel button could provide enough info to build the receipt page or other confirmation page, and the Webhooks notification could provide the notification in the event of the customer abandoning after the transaction. So for most scenarios (that aren't yours) an Accept Hosted specific out of band notification wouldn't really provide anything that Webhooks doesn't already provide.
@wp wrote:
This would be fine in a single-merchant scenario but since this particular application is designed for multi-merchant use, I don't know the authentication credentials to use for the API request to get the transaction details. That's why I need the notification to echo back an identifier from my own data so I can correlate it to a specific account on my end and then grab all the remaining data from there.
Yeah, that's more tricky. First off, do you mean you don't have the authentication details at all? Or that you just don't know which merchant you're receiving the Webhook for? I'm assuming that you have the actual credentials since you'd be using them in the token request. In that case, the Webhook notification itself includes a "webhookId", which would be specific to the merchant that requested it. Using that webhookId and matching that to the ID received when the Webhook was created, you'd know for which merchant you'd need to query the transaction details.
If you don't have the credentials at all, then I'm not sure what an appropriate workaround would be. I'd need to know more about how merchants are using your app to be able to think of ideas.
@wp wrote:
What is the likelihood something like this can be made available ASAP (like today/tomorrow) - either as additional payload data or via a webhook url that supports a querystring?
The possibility of any changes to the operation of Webhooks in the next couple of days is zero, unfortunately. Hopefully that webhooksId provides a workaround, though. Another possible workaround is to register Webhooks on multiple URLs. Even though you can't register a query string, you could still register multiple Webhooks with URLs like http://myserver.com/webhooklistener/merchant1, http://myserver.com/webhooklistener/merchant2, etc.
@wp wrote:
Considered both, but my understanding is Accept.js leaves the credit card input form on our server which increases PCI exposure. I started with iFrame but it was unclear as to how to implement all the moving parts required for the resizing and communications etc. There's lots of bootstrap and other scripts/styles/pages in that sample app that are unrelated to and unnecessary for the iFrame payment functionality. That's the problem with big multipurpose sample applications - trying to extract out just the parts you need from the parts you don't is very tedious and error prone. It would be much clearer to see a separate implementation of each hosted form approach containing just the most minimal, bare-bones, unstyled markup and scripting code needed to implement it.
Does such a thing exist anywhere?
I don't have a clear example like that here, but it would be great if some interested observer were to chime in with sample code for how they did it. I'll ask around, and if I can find anything, I'll share whatever I can find.
Accept.js works with a form that is created by your server, and served to the browser from your server, but the payment information from the form is never submitted back to your server, so it's not in the same scope as if you were receiving the payment data. However, since it is depending on the operation of a form that you have control over, it is in a different scope for PCI compliance than a hosted form like Accept Hosted.