Can/should we simplify Payment Messages?

[bummzack]

Payment messages currently have quite an extensive class hierarchy. Here's what this looks like:

PaymentMessage*
      |
      v
GatewayMessage*
      |
      +-> GatewayRequestMessage* ----------> PurchaseRequest
      |                                  +-> CompletePurchaseRequest
      |                                  +-> AuthorizeRequest
      |                                  +-> CompleteAuthorizeRequest
      |                                  +-> VoidRequest
      |                                  +-> RefundRequest
      |                                  +-> CaptureRequest
      +-> GatewayResponseMessage ----------> NotificationSuccessful
      |                                  +-> NotificationPending
      |                                  +-> VoidedResponse
      |                                  +-> RefundedResponse
      |                                  +-> CapturedResponse
      |                                  +-> AwaitingPurchaseResponse
      |                                  +-> PurchasedResponse
      |                                  +-> AwaitingAuthorizeResponse
      |                                  +-> AuthorizedResponse 
      +-> GatewayErrorMessage -------------> VoidError
      |                                  +-> RefundError
      |                                  +-> NotificationError
      |                                  +-> CaptureError
      |                                  +-> PurchaseError
      |                                  +-> CompletePurchaseError
      |                                  +-> AuthorizeError
      |                                  +-> CompleteAuthorizeError
      +-> GatewayRedirectResponseMessage --> PurchaseRedirectResponse
                                         +-> AuthorizeRedirectResponse

Classes marked with a * have own DB Fields and therefore a separate DB Table. So we have 32 Classes and 3 DB Tables. 29 of these classes just boil down to a different value in the ClassName Enum.

To easily inspect payment-messages, the fact that information is spread across 3 tables is more often than not a hindrance. Although it's probably quite rare that you'll check the raw DB table contents, it makes it also harder to consume the information from another (non-silverstripe) system.

My question is: What decisions lead to this architecture? Could it be replaced with a less bloated type of Payment-Actions Log? What role(s) do the Payment-Messages have to fulfill?

[mlewis-everley]

Just to get my penny in, I found this architecture a little overwhelming when I first started trying to get my head around the module.

It does seem a little bit like overkill if I am honest.

If the main difference is just essentially a "Type", and these types are unlikely to change, could you have a Status`Message\Type` field on the gateway message and define the possible types via a config variable?