Open mbjones opened 1 year ago
Initial thoughts on implementation sequence using Payconex's HostedForm utility that embeds an iFrame for encrypted credit card details.
%%{init: {
"theme": "forest",
"sequence": { "showSequenceNumbers": true }
}}%%
sequenceDiagram
participant Bookkeeper
participant Purser
participant Payconex
note left of Purser: Set up products form
Purser->>+Bookkeeper: GET /bookkeeper/v1/products
Bookkeeper-->>-Purser: productList
Purser->>Purser: showProductForm()
rect rgb(200, 223, 255)
note right of Purser: Create order and set up payment form
Purser->>Purser: checkout()
Purser->>+Bookkeeper: POST /bookkeeper/v1/order
Bookkeeper->>Bookkeeper: storeOrder()
Bookkeeper-->>-Purser: orderId
Purser->>+Payconex: update_iframe(orderid, productlist, amount, user details)
Payconex-->>-Purser: iFrame
end
rect rgb(170, 223, 255)
note right of Bookkeeper: Process payment and notify Bookkeeper
Purser->>+Payconex: pay(orderid, productlist, amount)
Payconex->>Purser: receipt
Payconex->>-Bookkeeper: POST /bookkeeper/v1/order/{orderid}/pay OrderStatus
activate Bookkeeper
Bookkeeper->>Bookkeeper: updateOrder()
deactivate Bookkeeper
end
Purser->>+Bookkeeper: GET /bookkeeper/v1/order/{orderid}
Bookkeeper-->>-Purser: order
A state diagram for order transitions. States from the SQL table definition comments.
stateDiagram-v2
direction LR
[*] --> Created
Created --> Canceled
Created --> Paid
Paid --> Returned
Paid --> Fulfilled
Canceled --> [*]
Fulfilled --> [*]
Returned --> [*]
Alternative with states from the Order.java representation class. I don't see any way to make these make total sense.
active|created|paid|past_due|refunded|trialing|unpaid
stateDiagram-v2
direction LR
[*] --> Created
Created --> PastDue
Created --> Unpaid
Created --> Paid
Created --> Trialing
Paid --> Refunded
Paid --> Active
Trialing --> Active
Active --> [*]
Refunded --> [*]
Alternative as a hybrid of these to be evaluated:
active|created|paid|expired|refunded|trialing
stateDiagram-v2 direction LR [*] --> Created Created --> Paid Created --> Trialing Trialing --> Paid Paid --> Paid Trialing --> Expired Created --> Canceled Paid --> Refunded Paid --> Expired Canceled --> [*] Expired --> [*] Refunded --> [*]
Initial design of PaymentsResource implemented in SHA dcdd9e80587 and SHA 523034a52237. The new REST service lives at the endpoint /bookkeeper/v1/payments
, and the only implemented method is currently a POST which enables creation of a new payment transaction. This transaction takes the form of a postback transaction log from the transaction processor (in this case Bluefin Payconex) which has the following format:
Still much to do, including:
Order.pay()
when a transaction is approved to update quotas and usages and migrate state transitionsRevised diagram on implementation sequence using Payconex's HostedForm utility that embeds an iFrame for encrypted credit card details, with the new approach of using postback transaction receipts to finalize the transaction on the server side:
%%{init: {
"theme": "forest",
"sequence": { "showSequenceNumbers": true }
}}%%
sequenceDiagram
participant Bookkeeper
participant Purser
participant Payconex
note left of Purser: Set up products form
Purser->>+Bookkeeper: GET /bookkeeper/v1/products
Bookkeeper-->>-Purser: productList
Purser->>Purser: showProductForm()
rect rgb(200, 223, 255)
note right of Purser: Create order and set up payment form
Purser->>Purser: checkout()
Purser->>+Bookkeeper: POST /bookkeeper/v1/order
Bookkeeper->>Bookkeeper: storeOrder()
Bookkeeper-->>-Purser: orderId
Purser->>+Payconex: update_iframe(orderid, productlist, amount, user details)
Payconex-->>-Purser: iFrame
end
rect rgb(170, 223, 255)
note right of Bookkeeper: Process payment and notify Bookkeeper
Purser->>+Payconex: pay(orderid, productlist, amount)
Payconex->>Purser: receipt
Payconex->>-Bookkeeper: POST /bookkeeper/v1/payments Payment
activate Bookkeeper
Bookkeeper->>Bookkeeper: validateTransaction()
Bookkeeper->>Bookkeeper: processPayment()
Bookkeeper->>Payconex: HTTP 200 or Error
deactivate Bookkeeper
end
Purser->>+Bookkeeper: GET /bookkeeper/v1/order/{orderid}
Bookkeeper-->>-Purser: order
note right of Purser: Update UI based<br> on order status
We have a merchant account through Bluefin Payconex (see payconex developer docs) and need to integrate that in with bookkeeper. See the overview of the process from the dev docs:
The basic flow would be that: