Handling Status Dilemma

This my approach for this problem:

1. I add a column status with type string in the orders table.
2. Define the constant of all your statuses in your class so you can reference them easily.
3. Make a validation rule on creation of order that the status value is in the only allowed ones you defines earlier.

This makes adding a new status very easily by just editing your code base, and the retrieved value for the status is still a string (descriptive).

I hope this answer your question.

I suggest this:

1. Store in DB as status(unsigned tinyint, char(5)).
2. Id must be powers of 2: 1,2,4,8,...
3. At backend code const name must be humanized, but value -- int: const PAID = 2
4. At backend you should not use consts directly, but use status class object, which will contain some methods like value and name.
5. This class's test will check that all of it's values are in DB and all DB's values are covered by class.

space for human errors

Tests invented to avoid human errors.

Statuses are usually not so complex and has not so many values to mess with them.

Enum is evil. http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

Regarding your proposal:

The database is well defined and normalized

No. It's denormalized.

The returned data from the API is descriptive and deliver the required meaning.

You always can use wrapper, that goes into status table to get human name.

The status constants used already contain their meaning which reduces the chances of errors.

Const name are for humans and values are for Benders.

Adding a new status constant is simple with INSERT command in the status table.

Same in 1st and my solution.