search

balanced / balanced-api

Balanced API specification.
220 stars 72 forks source link

Materialized orders view #690

Open kyungmin opened 9 years ago

kyungmin commented 9 years ago

What backend changes do we need to make to be able to

  1. display transactions by payment_group_code,
  2. pre-populate payment_group_code when users create credits/refunds on a debit in the dashboard
mjallday commented 9 years ago

We could do something like

GET /grouped_payments

{
    "orders": [
        {"id": "payment group code 0", "credits": [...], "debits": [...], "refunds": [...]}
        {"id": "payment group code 1", "credits": [...], "debits": [...], "refunds": [...]}
    ]
}

Essentially it would have the same schema as an Order but you cannot update it.

This could be a read-only view that's made accessible via revision 1.1 only. The ID could be the payment group code itself.

We'd probably want to document this if we're going to keep it around, IMO the better solution would be to provide a tool to convert these into full fledged first class orders but that may be harder since it would require customers to know when the migration occurs.

mjallday commented 9 years ago

ping @balanced/spec-ialz

matthewfl commented 9 years ago

I don't think it makes since to use the payment group code as the id, since these aren't unique accross marketplaces, also they can contain spaces and other strange characters such as # which would make them annoying to use as urls.

As for creating an order, at one point in time I was thinking that a way could be provided where an order is created from a set of existing transactions and then the system could check all of the order constraints at one time and then reassociate the given transactions and update the internal accounting etc.

mjallday commented 9 years ago

since these aren't unique accross marketplaces

good point. md5(payment_group_code + marketplace.id) then :)