Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How would one model an "auth-capture" scenario? #21

Open
max-earnin opened this issue Jan 27, 2021 · 2 comments
Open

How would one model an "auth-capture" scenario? #21

max-earnin opened this issue Jan 27, 2021 · 2 comments
Labels
documentation Improvements or additions to documentation

Comments

@max-earnin
Copy link

I'm exploring sequence and trying to apply it to a problem where an account may "promise" to pay up to X, and then end up paying Y (where typically Y < X). So if I start with 100 in my ledger, and promise 50, my balance is still 100 from one perspective, but I only have 50 left to promise. Then as that promise is resolved as 30 instead of 50, my balance is 70, and I have 70 left to promise.

Would this be best as two separate ledgers? One ledger with metadata distinguishing promises from movements (but balance computation becomes hard)?

Thanks!

@sandyscoffable
Copy link

sandyscoffable commented Jul 19, 2021

AFAIK this is more of an accounting problem. You'd represent this with multiple accounts in an accrual accounting manner. So perhaps something like:

Starting state
Bank Account: 100
Funds Available: 100

Auth
Funds Available: -50
"I promise to pay" Account: +50

Capture
Bank Account: -30
"Paid" Account: +30
"I promise to pay" Account: -50
Funds Available: +30

The advantage of this is you can see:

  1. How much money the bank account should have in it right now
  2. How much money has been paid out
  3. How much money has been ringfenced for payout
  4. How much money is remaining to be spent (i.e actual balance - future ringfenced amount)

@andriosrobert
Copy link
Contributor

As @sandyscoffable mentioned, I wouldn't use separate ledgers; just create intermediate accounts for any money movement/state you need. This is why it is super important to have a ledger that has a simple API, doing this type of thing should be straightforward in a good ledger implementation.

@andriosrobert andriosrobert added the documentation Improvements or additions to documentation label Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants