Payment Limits during Load Testing

[vale path]

Hi everyone,
I'm currently running load tests on a client's platform using the Mollie API and would like to know if there are any limitations or quotas on the number of payments that can be created concurrently. Are there any specific restrictions or best practices to consider during such tests?
Thanks in advance for your insights!

[sinful sand]

Hi Toony,

Welcome to the community! 👋

You should not test against our API, use a Mock API instead. We use dynamic rate limiting, so the limits differs over time.

[vale path]

Thanks for the quick response! I'll switch over to using the mock API as recommended. However, since retrieving the payment status is still within our test scope, do you have any recommendations on how to generate a large number of valid payment IDs? Any best practices or tips for simulating this accurately would be greatly appreciated.

[sinful sand]

Basically the same answer. You should never test against supplier APIs 😄

Just set up a Mock API in your tests and feed those with the datasets you are looking for

[dawn aurora]

When you hit the rate limit, you'll get a 429 response back. That 429 response has a retry-after header that contains the time you need to wait before making the next API request.

[sinful sand]

But even then, doing real API calls to a suppliers in tests is a bad design

So please, use a mock API

[dawn aurora]

That depends, for end-to-end tests I would prefer to call real sandbox/test API's.

I do agree that running load tests against external API's is not recommended, but you do need to make sure that your system handles the rate limit and 429 errors gracefully. For example by automatically retrying these requests after the retry-after delay.

You could also try to implement a rate limiting behavior similar to the one Mollie uses in a mock API. That way you could make it as close to a real life scenario as possible, without sending a lot of requests to the Mollie API.