customers: support additional implementations

[adamdecaf]

PayGate Version: v0.8.0

What were you trying to do?
Some users of PayGate want to use a different implementation of Customers. This is because they have an external KYC/CRM system and don't need to track Customer information in our services. What complicates this is account information which is required by PayGate. We need to figure out how to pull that account and customer information. It might be easier to split the interface.

Configuration

I think adding a sub-object in the config file for new implementations would be the way to go.

Required Calls
From the v0.8.0 Customers client there are a few required calls. We can split these out into a different Go interface.

• FindAccount(customerID, accountID string) (*moovcustomers.Account, error)
• DecryptAccount(customerID, accountID string) (*moovcustomers.TransitAccountNumber, error)

We require several fields of the Customer model as well.

[chanhengseang3]

The idea is to send Customer data and Account data as json by the time creating transfer itself. Neither paygate nor any other service will store Customer and Account separately.

Creating transfer should look like :

{
	"amount": 123
        "source": {
		"customer": { ... } // customer data
                "account": { ... } // account data
	}
       "destination": {
		"customer": { ... } // customer data
                "account": { ... } // account data
	}
      "description": string
      "sameDay": boolean
}

[vishwasbabu]

To add to the previous comment and the issue description, this change would enable existing modular cores to easily connect with ACH infrastructure (through paygate) without needing to orchestrate the low-level API's provided by the ACH project.

We would assume that an existing core has

• Customer management with KYC
• Account / ledger management

and is only looking to call PayGate to pass all payments related data through a simple API. So the existing API would introduce optional parameters as shown below

{
  "transferID": "dd4dfea8ea5fe52d46d9749fc84ad6695d3d2a05",
  "amount": "USD 1.25",
  "source": {
      "customer": { // optional parameter that can be used in-lieu of existing customerID
      "fullName" : "BigShot Inc." //can be used for both retail and corporate customers
     },
    "account": "{ // optional parameter that can be used in-lieu of existing accountID
      "accountNumber": "123456789",
      "routingNumber": "498764352",
      "type":"checking"
    }
  },
  "destination": {
     // similar optional changes as in source
  },
  "description": "test transfer",
  "sameDay": false,
  "created": "2020-07-10T16:59:19.6422361Z",
  "schemeSpecificOptions": // New array that allows paygate to introduce optional scheme-specific behavior for supporting niche use cases without breaking the existing API
    [
      {
        "fieldName" : "SEC",  // ACH scheme specific parameter
        "value":"CCD" // Paygate can now set the SEC code to CCD instead of the default PPD. Similarly, additional options for Credit / Debit addendas, etc can be added
      }
   ]
}

I will follow up on "schemeSpecificOptions" later on as we integrate with more US payment schemes and have more specific use-cases.

[adamdecaf]

We're looking to have CCD be determined by the Customer type on source/destination rather than allowing such an override.

I'm still unsure if we want to accept full customer blocks for these transfers. I think supporting another Customers impl makes more sense than expanding the API endpoint.

[vishwasbabu]

@adamdecaf : Fair enough. Just an update that we ended up using the ACH project for our use-case