Materialized orders view

[kyungmin]

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]

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]

ping @balanced/spec-ialz

[matthewfl]

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]

since these aren't unique accross marketplaces

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