With this release we extend our existing payment APIs, and also add a brand new one: now you can also refund money, in case someone paid too much.
Pay by invoice
...or "Check out on AR (Accounts Receivables)", how the pros call it. We added a new endpoint on the FolioActions API, 'checkout-on-AR', and secured it with its very own scope, 'folio.checkout-ar', as allowing customers to leave the hotel without paying needs extra protection. The function is only available when it's clear that no additional charges or payments will occur, for example after a checkout or cancellation.
Calling this endpoint will post the payment as "invoice", close the folio, and do all the required accounting transactions. When you generate an invoice that has an invoice-payment, the payment terms you specified when creating or updating the property (in the inventory API) will be added to it.
Even though the apaeo APIs prevent overpaying a reservation, it can still happen that a guest ended up paying too much: the cancellation fee is lower than the total prepaid amount, the guest gets a discount on a room that wasn't as quiet as advertised, the no-show fee is waived, etc.
Now you can fix this by calling 'refund' on the FolioActions. Like checking out on AR, this has its own scope ('refunds.create'), as not everyone is allowed to give away money.
Note that posting a refund on apaleo does not (yet) automatically trigger a refund with the integrated payment provider.
More fine-grained payment types
We thought our accounting module is small, but great! That thought didn't survive for 5 seconds after we showed it to customers. "What kind of payment is 'CreditCard'? How should I be able to follow up with the credit card companies, and check that what they paid me is what I have in my books?" Valid point. We quick-fixed that, and when creating payments, customers can now select from the world's most common credit and debit cards. If you don't care about those details (and for backwards compatibility) we left the 'CreditCard' payment type.