@wp and @vedranmimic,
I'm not aware of any issues using Accept Hosted on a live account. That should work just the same way as it does on the sandbox account. If it's not working that way for you, check in the merchant interface for the live account to make sure that the live account has a "Signature Key" associated with it.
Accept Hosted is officially released, but in more of a public beta form. That means that we consider it production ready but with some limitations. I'll go into more detail about the limitations here, but first off, thanks so much for the time you've both taken to write these posts and emails. They're super helpful to us, so even if they don't get you the good news you want to hear, they allow us to clearly identify issues and provide the feedback of how they affect developers. That's what we really need to hear with a new product or feature. It takes time to write a coherent clear message giving constructive feedback like you both have, so I really appreciate the effort.
You've identified a few issues here:
- The token request fails if the account doesn't already have a "Signature Key" created in the merchant interface.
- Following any URL from the payment form is just a GET request, not a POST with relevant data.
- There's no Accept Hosted specific additional way to receive this data (like a simultaneous post from our system to a URL on your system when the transaction is approved).
- Our general purpose notification system (Webhooks) doesn't provide the info in the notification that you would need in this scenario to know which transaction you're being notified about.
- Webhooks doesn't let you register a URL with query strings embedded in it.
- Documentation could be clearer (and includes a couple of errors)
The good news is that all of these are being addressed, but the bad news is that not all of the improvements will appear right away.
Documentation updates are probably the quickest to get out, so we're trying to update that ASAP. @vedranmimic already touched on the known errors (the reference to "receiptPage" should read "showReceipt"; the hostedPaymentIFrameCommunicatorUrl needs to be passed a JSON object). However, there's a lot more that's been written and that we're trying to include to clarify usage based on feedback like this.
As far as other fixes go: We do have plans to pass more data back in the redirect scenario when the continue or cancel buttons are clicked. However, even if/when both of those buttons turn into POST requests instead of GET requests and submit all of the transaction data to your server, that still won't cover the scenario where a customer submits a card and gets authorization, only to immediately close the browser or have the computer crash. There still needs to be some out of band notification to you that a transaction took place. That's where Webhooks comes in.
You're correct that the existing Webhooks notification by itself doesn't include enough info for you to tie it to a specific customer's payment session. There are already requests to specify more info to be included in the notification (and to allow query strings to be included in a Webhooks URL). However, what we recommend is to take the transaction ID included in the notification and do a getTransactionDetailsRequest for the full transaction details. Using something like the invoiceNumber or purchaseOrderNumber from the transaction details would let you correlate to your customer.
@wp, hopefully this is enough further info for you to determine if this solution will work for you. Currently in a redirect scenario, confirmation of a successful transaction will only be available if a customer clicks on the continue/return button, via Webhooks notification, or via the merchant interface. Detailed transaction info will only be available via Webhooks notification (with subsequent getTransactionDetailsRequest) or via the merchant interface.
If Accept Hosted isn't going to work for you in a redirect scenario, there are other options including calling the Accept Hosted form within an IFrame. If that's still not suitable, the Accept.js solution allows you full control over the payment form and the payment processing while keeping the actual payment details out of your server, thus reducing PCI scope.
If there's any outstanding questions, or anything you still need answered, please let me know.
Again, thanks for the feedback!