Our final status code mapping is tightly coupled to the get_orderstatus API call, but in reality we interpret status codes from many operations using the same mapping. Some statuses have special meanings depending on context, for example a status 600 refund needs to get poked by a SET_REFUND rather than a SET_PAYMENT. This is a harmless one, but we should make it clear when statuses have special meanings.

finalstatus::complete is another example--when a refund is complete, we should call it finalstatus::refunded so that we don't accidentally fall into a "successful transaction" code path when the refund context is obscured.