3

I am currently implementing Adyen Web Drop-in integration but ran into a problem testing it on staging.

From the Adyen developer console I can see the API request and response for the session endpoint which returns the sessionData payload as expected.

session log

We then pass sessionData into a page which renders the form correctly.

<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

    <script src="https://checkoutshopper-live.adyen.com/checkoutshopper/sdk/5.10.0/adyen.js"
            integrity="sha384-LoKEanRPljHoEsT5o+grBn8hgVzoPevwGvRd+gOp/2Xgc4Jx2FQkx29092SKDdeY"
            crossorigin="anonymous"></script>

    <link rel="stylesheet"
          href="https://checkoutshopper-live.adyen.com/checkoutshopper/sdk/5.10.0/adyen.css"
          integrity="sha384-DB96UxMFf+ytuAxtum6/9TOoG/y+vUDFbqolCb7OcQvBA+qSrGaRrl81nMADo/+9"
          crossorigin="anonymous">
</head>

<body>
    <div id="dropin-container"></div>
    <script type="text/javascript">
        (async () => {
            let checkout = await AdyenCheckout(${partnerJsonParameters?string});
            checkout.create('dropin').mount('#dropin-container');
        })();
    </script>
</body>
</html>

Upon filling in the form with a test credit card number and clicking Pay I see two requests in the browser network pane, CORS pre-flight which is fine, and then the second request fails with

{"status":403,"errorCode":"010","message":"Not allowed [This error message is only provided on TEST, this error will be a 500 Internal Error on LIVE.]","errorType":"security"}

I have found two articles on this error, https://www.adyen.help/hc/en-us/articles/360014216000-Why-do-I-receive-a-403-or-010-Not-Allowed-error- and https://docs.adyen.com/development-resources/error-codes#010-not-allowed but the roles seem fine.

roles

I have verified that both the session from server side and checkout config are configured with "test" environment.. any pointers on what else I can try?

Johno Crawford
  • 478
  • 1
  • 6
  • 16
  • Hi Johno, you don't need to enable the `Management API` roles (those are to change the configuration via API calls), the rest looks ok. Can you try to enable the `API PCI Payments role`? – Beppe C Mar 21 '22 at 16:00
  • @BeppeC thanks for the response, where can I find that role? from what I can see everything that I can enable is checked. – Johno Crawford Mar 21 '22 at 16:15
  • Drop-in should only require the role "Checkout encrypted cardholder data" which we have enabled.. still at a loss at what the problem might be. – Johno Crawford Mar 21 '22 at 17:03
  • Matthew added API PCI Payments role to our account, but the same error is returned. – Johno Crawford Mar 21 '22 at 17:44
  • Thanks John, this was to make sure there was no issue with the card encryption (the role it send credit card raw data and indeed you don't require that if you use the Drop-in - please uncheck it) – Beppe C Mar 22 '22 at 07:55

1 Answers1

3

After a bit of back and forward with Matthew here's the solution.

We have seen this error happening before on the test environment, and the best way to resolve is to use another API user. Would it be possible to create a new API user as described here, or use another of the existing ones? Using the API Key and Client Key from the new user should resolve the issue.

Johno Crawford
  • 478
  • 1
  • 6
  • 16
  • 1
    Thanks for posting the solution. I would call this a 'workaround' and we will investigate further to understand the cause and address it. I understand that your integration now works (with a new API credentials set), if you still have troubles please let me know – Beppe C Mar 22 '22 at 08:01
  • 1
    That's correct, thanks for following up! – Johno Crawford Mar 25 '22 at 09:28