Unified Money Movement Services (UMM) provides distinct product lines tailored for Banks, Credit Unions, Fintechs, and other Financial Institutions. These product lines are categorized according to the institution type utilizing the UMM Service and the nature of integration.
| Client Type | Purpose | Integration Type | API |
|---|---|---|---|
| Banks, Credit Unions | Account-to-Account (A2A) Transfers for Retail and Business Clients | Via Digital Banking Platforms maintained by the Bank/Credit Union | Transfers & Payments |
| Fintechs (excluding Banks/Credit Unions) | Transfers, Payments, Collections, etc. | Via third-party initiation | Integrated Payments |
In addition to product-specific APIs, UMM also provides a suite of Administrative APIs. This includes the Health Monitoring API, which oversees all APIs offered under UMM Services.
In this authentication scheme, UMM Services would send API Keys, in the form of HTTP headers, as part of the webhook. These API Keys must be configured in UMM Services by the client. A client can specify upto a maximum of 5 API keys to be sent in a webhook. The client can check for the authenticity of the webhook by comparing the API keys and values received in the webhook with the ones configured in UMM Services.
Example :
test_header1:value1
test_header2:value2
test_header3:value3
test_header4:value4
test_header5:value5
With Basic Authentication, UMM Services sends a Base64-encoded string that contains the user name and password for the client in the Authorization header of the HTTP request. The client must configure the username and password for the basic authentication in UMM Services. The client can check for the authenticity of the webhook by verifying the username and password received in the webhook with the ones configured in UMM Services. Please note that Base64 is not a form of encryption and is similar to sending the user name and password in clear text.
Example :
Below dXNlcm5hbWU6cGFzc3dvcmQ= refers to Base64 encoded string of the provided username and password ( username:password )
( : ( colon ) is appended in-between username and password before it is being encoded)
Authorization:Basic dXNlcm5hbWU6cGFzc3dvcmQ=
UMM Services supports Open Authorization Protocol 2.0 with Auth scheme as “Bearer”. The client/biller needs to run an authorization server at its end. The client needs to configure the client id, the client secret, the token endpoint (URL) and the Auth scope in UMM Services. The Grant Type to be used is "client_credentials". UMM Services sends the token read from the token endpoint in the Authorization header of the webhook.
Example :
Below 4484e52dc4744374aced826a4543cd28948816ff refers to the access token issued by Autherization server.
Authorization:Bearer 4484e52dc4744374aced826a4543cd28948816ff
Every webhook request will include the following headers
| client_key required | string <= 10 characters ^[a-zA-Z0-9]{1,10}$ The unique identifier assigned by the UMM Services to the client. |
| product required | string <= 100 characters ^[a-zA-Z0-9_.& -]{1,100}$ The product identifier corresponding to the API. |
| payment_channel required | string <= 100 characters ^[a-zA-Z0-9_.& -]{1,100}$ The FI channel vide which the API is invoked. |
| idempotent_request_key required | string <= 50 characters ^[a-zA-Z0-9_=-]{1,50}$ The unique token that clients can generate and maintain in order to identify an API request. This is used to identify duplicate requests and retrials. |
| timestamp required | any <ISO 8601 DateTime with offset YYYY-MM-DDThh:mm:ss.sss+/-hh:mm> The UTC datetime when the API is invoked, in the ISO 8601 format |
© 2022 Alacriti Payments LLC. All Rights Reserved
