You don't need to go full HATEOAS to consolidate most business logic in server-side API. Like, this is just an example of an awkward API that exposes `status` and `validation` and makes clients do the business logic, rather than one that exposes `hasInvoice` and/or `invoiceId`. The HATEOAS bit is sending across a URI instead of a resource ID, which only helps when there's business logic for which endpoint to use for a specific resource ID that needs deduplication. And even that is only necessary when the client must make the request directly and can't proxy through a "figure out which endpoint to use and delegate it" endpoint.

To be specific, HATEOAS would help when Visa and Mastercard need to use different endpoints for the invoice, and the payment networks require the client to directly query their endpoint rather than going through a server API you control.