• Impact of security measures on Business accounts

The new security measures do not seem to take Business accounts that use the API into account. We rely on this feature to send payments to IBANs, but are now unable to do so. Furthermore:

  • The error is a HTTP 474 response code with a message to retry in 24 hours, which is undocumented.
  • This means programmatically, API users need to build logic to retry after 24 hours.
  • And if you retry within those 24 hours, the timer gets reset to an additional 24 hours.
  • The error message is unstructured text rather than eg JSON so parsing the expected retry time from it is unreliable.
  • Does this security measure make sense at all in the context of Business account API users in the first place?

    Hey @Choong-Cyan-Cheetah#293549 👋 Thanks for being a part of our community and sharing your concerns!

    We've forwarded this to our relevant team for review so we can get this sorted out as quickly as possible.
    We appreciate your feedback as it helps us to grow 🌈

    In case if you have any further questions, you can always reach out to our support. You can find the details here 🚀

      @Choong-Cyan-Cheetah#293549
      Same problem here. Contacted support and told them this is unworkable for a business account. I need my paiments send directly and not have to wait 24 hours. It is also for existing IBAN and not only for unknown.
      Support told me bad luck and this is the new security measurement they have taken and I have to live with it.

        Hey there @Dennis-Blue-Panda-2797653505#293572, @Choong-Cyan-Cheetah#293549 Thanks for sharing your experience 🙏

        For now, we do indeed recommend building a retry logic, you can use the time_execution field as indication for the time period to try again from the error body instead of parsing it out of the error message.

        If you continue having issues, please feel free to reach out to us via email at apipartner@bunq.com where our dedicated team will help you out accordingly 🚀

          @Choong-Cyan-Cheetah#293549 Do you maybe create a new device-server / ApiContext for every payment or batch? Or do you load an existing context from file/database?

          Because maybe it “thinks” it’s a new device if you create a new device-server for every session, so the payments get delayed.

            @Choong-Cyan-Cheetah#293549
            Did you succeed in sending the payments? I got the same error on Friday and stopped the script from executing. Today (more than 24 hours later) I fired up the script again but still all payments get rejected with the same message: You cannot make this payment right now. Please try again after [now+24h]

              @Dennis-Blue-Panda-2797653505#293631 what method do you use in your script (see my previous message above)?

                @marko-#293577

                For now, we do indeed recommend building a retry logic

                Thanks for the info, we might. But sincerely, we are actually hoping Bunq will revert this behaviour. Of course we as one single customer only have a limited view on your business concerns, but if the goal here is to protect consumers from getting scammed (as described in recent media attention), then I'd argue blocking API calls for Business accounts in this manner seems excessive. What does this feature protect against in this context? Shouldn't it be up to the Business user's software to decide which IBANs are appropriate to transfer money to?

                Furthermore, in all honesty, as an API user I'd expect a b/c breaking change like this to be announced on beforehand. For the short term we've now worked around this by having a developer manually retry these failed calls after 24 hours, in the evenings and weekend. It would have been great if we'd been alllowed some time and documentation to properly implement an automatic retry mechanism for this. This change seems to have gone live unannounced last Thursday, causing developer "overtime" and some amount of chaos within the organisation as a whole as we tried to figure out the impact and work-arounds, how to communicate this to our customers, etc

                  @Bastiaan#293624 Thanks for your reply. We re-use the existing context. In the meantime we have successfully been able to send some payments that got caught in the 24 hour "wait list", so it seems to work as intended for us.

                  @Dennis-Blue-Panda-2797653505#293631 We have since successfully sent out multiple payments that were getting blocked for 24h initially, so it seems to work as inteded. As Bastiaan mentions, we do re-use existing device-server and ApiContext.

                    @Bastiaan#293633
                    I restore the apicontext from a file. Worked for years this way. I paid to these accounts hundreds of times. But also if I would create a new device-server every time and that would be the problem, then they should not call it AI driven. Then it is just: if one of the following conditions is met: deny payment.

                      Write a Reply...