Balancing fees of user account

[ndege]

E-payment of user fees becomes more popular last years. Therefore a specification in PAIA would be logical. One reliable method will be a balancing of fees via transaction ids. The draft I would suggest tends to joins the PAIA method fees with an additional subordered method for balancing single fees at the user account. Other concepts as paying all fees / the amount can also be mapped in this way but not in the other direction. In my opinion it's better the system only knows which IDs should be paid and returns the successful balanced IDs.

purpose
    Balance current fees of a patron. 
HTTP verb and URL
    POST https://example.org/core/{uri_escaped_patron_identifier}/fees/balance 
scope
    balance_fees 
request parameters 
   name      | occ | data type |  description
   fee          | 0..n | array        | list of fees that SHOULD be balanced
   fee.feeid | 0..1 | URI          | URI of the type of service SHOULD be balanced
response fields
    name               | occ | data type | description
    balanced          | 0..n | array        | list of successfully balanced fees
    balanced.feeid | 0..1 |  URI         | URI of the type of service that is balanced  

[nichtich]

I see several problems with this request:

• By now, individual fees don't have an identifier. A user may have two identical fees with same feeid (this only identifies the type of fee) so it's not possible to select which one to balance.

• How to prevent users from balancing their fee for free? The balance_fees scope would allow to clear all fees

• Which library actually requires this feature?

As far as I understand, E-payment must be legitimated against some kind of bank account and the library will get a confirmation of the payment via the bank, so it can better internally balance the user's fees. PAIA only provides a view to the current amount of fees.

[ndege]

Thanks @nichtich I'll review my proposal due to your hints and understand to begin with reconsidering the view of fees.

For the context, first consideration is that use of e-payment can be very versatile so we like to reduce it on balancing the fees and let all proper transaction processing outside at first. Second we follow the approach that every participated component communicate in a bidirectional way so that if the client start to pay his fees at the catalogue on basis of the fees view the response and corresponding balancing of the account should be made to the same endpoint. In our case spoken truly, the real transaction will be passed between third party software components and we need the new PAIA request only to refresh the fee view of the logged user at the ILS in real time. As payment service our institution UB Leipzig like to introduce ePayBL soon, but we've even other partner institutions interesting in as e.g. TU Freiberg.

[tzeumer]

• Which library actually requires this feature?

TUB HH and other libraries use SIP2 (Gossip) for paying fees. This works well and is very fine for the time being (meaning the currently used hardware/software supports it and SIP2 is still pretty common; even though not always well understood and implemented by vendors). Since DAIA/PAIA already can do most things that are possible with SIP I find the idea of payment capabilities attractive, too. Maybe something like ePayBL (never heard, thanks for the hint) might be possible to set up with Gossip, but PAIA would appear as a more straight forward choice.

As a side note: Gossip v2 introduced a possibility to pay ILL fees. While I'n not exactly sure how the connection "local" library account to "remote GBV" ILL account is accomplished, it is a highly attractive option (as would be any other closer connection between those two accounts).

[nichtich]

Thanks. Connection between multiple accounts is an independent issue, but I don't understand how "paying" fees should work with an API. How should the PAIA server verify that a patron has actually paid the money? Do you want PAIA to receive one-time secrets that allow to clear some amount of money (so these secret tokens would be like vouchers to clear your fees)? Support of cryptocurrencies would be more of a nice April fools joke, wouldn't it?

[tzeumer]

Is it basically thinkable that some features are only available with some kind of admin authentication? This might be a user/password combination; either to be set in a PAIA config file (would appear to be the common way) or maybe an extra flag for an admin login (verifying versus the library systems inbuilt account(s)), that works similar to a patron login, but allows to act on another token with broader permissions. Or am I thinking to simplistic?

[nichtich]

The specification does neither forbid access tokens to be usable for admin-like tasks like being being able to change data of any patron. Nor does it forbid to issue access token via other means than via the pubic login method. Looks like all you need in the specification is an additional write_fees scope and HTTP PUT or HTTP PATCH at fees endpoint to set fees. The rest (how to obtain a token with scope write_fees, whether fees can be set to arbitrary values or only cleared...) is left to the implementation of PAIA servers that choose to support write_fees.

[UschiKlute]

For your information: In the long term one of the GBV libraries plans to use ePayBL.