Service Descriptions

B2C
Account Service

Description

Account service is used to perform account related operations that happen in any banking/wallet app or interface including and not limited to

  1. View Balance a. Account Balance b. Ledger Balance
  1. View Transactions with filters
  1. View Transaction Details
  1. View/Update KYC associated with a particular account entity This account is different than user “user account/profile” login. KYC process is generally per account entity wherein say a bank account will require a National ID but an another account entity like a wallet may require National ID and Passport as KYC which both fall under same users

Technology

It will have providers registered to it. Each provider will be generally a parser which will map the response and request from our client touch-points to what external banking and account systems understand and vice versa. Provider will come with its own set of configurations and rules.

Database will have KYC related steps via its KYC sub module For eg: Our API will have a certain response structure which we want it to be uniform across and irrespective of what accounts are we showing. Bank 1 may give us balance under the key name of balance while Bank 2 would give us under the key name of account_balance

Cards Service

Description

Card service is used to configure and control card related things like

  1. Card Block
  1. Set PIN
  1. Domestic Usage and Limits • POS • ATM • Online • Tap and Pay
  1. International Usage and Limits • POS • ATM • Online • Tap and Pay

Technology

It will have providers registered to it. Each provider will be generally a parser which will map the response and request from our client touch-points to what external card management systems and schemes understand and vice versa. Provider will come with its own set of configurations and rules.

Database will have cards via masking/tokens and user mappings only. All other controls will only be setter and getter to external systems and we won’t store that data For eg: Our API will have a certain response structure which we want it to be uniform across and irrespective of what accounts are we showing. Bank 1 may give us balance under the key name of balance while Bank 2 would give us under the key name of account_balance

Transfer Service

Description

Transfer service is used to perform transfer of money from a source account to a destination account with different combinations

  1. Local Transfer a. Same bank transfer b. Another bank transfer c. Bank to wallet transfer d. Wallet to bank transfer
  1. International Transfer a. Bank to bank transfer b. Bank to wallet transfer c. Bank to card transfer d. Wallet to card transfer e. Wallet to bak transfer

Technology

It will have providers registered to it. Each provider will be generally a parser which will map the response and request from our client touch-points to what external remittance partners understand and vice versa. Provider will come with its own set of configurations and rules Database will store contacts and their accounts mapping to populate to the user. Since different accounts have different fields, a document data type column is required for the same. Although its not a broader set of unstructured data that we have to use Cassandra or similar database, we can use Postgres JSON data type for the same. On the user front we will show them masked numbers of accounts like xxxx-8451 Orders placed through transfer service will go through Orders Service for future reference and status tracking

Bill and Utility Plus Service

Description

Bill and Utility Plus service includes below services in home as well as work country

  1. Bill and Utility Payments a. Recharge b. TV c. Fees d. and similar more as supported by partners
  1. Insurance a. Vehicle Insurance b. Medical Insurance c. Life Insurance

Technology

It will have providers registered to it. Each provider will be generally a parser which will map the response and request from our client touch-points to what external insurance partners understand and vice versa. Provider will come with its own set of configurations and rules Orders placed through the service will go through Orders Service for future reference and status tracking For eg: A recharge service in some countries would come with recharge code to be punched in dialer to recharge vs direct recharge happening in some countries. An insurance order would have options to download policy document, initiate claim, check benefits.

Order Service

Description

Order Service is a records service cataloging all orders with their current status and details. There will be different type of orders and in that sense details inside will change. Few of the examples are

  1. Bill Payment and Utility Orders Details would be having recharge code, transaction id, payment methods, what plan purchased
  1. Insurance Details would have an action button of making claims, benefits summary, action to download policy document
  1. Remittance Details would have status of the remittance, amount details along with breakup of charges and forex exchange rate The question arises why would we require a remittance order as transfer will happen from the account itself and we can check if deduction happened. But we will need to status of remittance which will unavailable from transaction and its details itself. Also in case of failure how the banking works is that there will be two transactions one of debit and another of credit as reverse.

Technology

Order Service will fetch order list via pagination and common details from various types as described above Database will be combination of relational database Postgres wherein we will store payment gateway transaction_id, order_id, status, timestamps and unstructured JSON data as per types above.

Master Service

Description

Master Service is a static and CMS service which will give you below

  1. Countries
  1. States
  1. Cities
  1. Currencies
  1. Languages
  1. Onboardings
  1. Sliders
  1. Settings

Technology

Database will be Postgres

B2B
Master Service

Description

Master Service is a static and CMS service which will give you below

  1. Countries
  1. States
  1. Cities
  1. Currencies
  1. Languages
  1. Package
  1. Services
  1. Employees
  1. Companies

Technology

Database will be Postgres and a GraphQL layer on top of it

Order Service

Description

Order Service is a records service cataloging all orders with their current status and details.

  1. Services Services ordered by employers and recruiters
  1. Employees Employees in that order
  1. Status Status of individual services and order as a whole
  1. Ticket Tickets of services which will have conversations and attachments
  1. Quotation Quotations generated for an order

Technology

Order Service will fetch order list via pagination Database will be Postgres wherein we will store payment gateway transaction_id, order_id, status, services, packages, timestamps

Workflow Service

Description

Workflow Service is an event driven service which performs a set of tasks when a certain event occurs

For eg: When an order is created attach all services to it. When payment gets cleared for that order after accepting a quotation then create tickets of all services individually and notify relevant subscribers/stakeholders

Technology

We will use Temporal to define workflows

Common and Miscellaneous
Auth Service

Description

Auth Service to have following features:

  1. Username
  1. OTP based
  1. Password based
  1. MFA
  1. Tenant or Application to create separation between different systems
  1. Session based
  1. Token based
  1. OAuth and SSO
  1. Secure

Technology

Using out of box IDP provider like Fusion Auth, Ory, Casdoor and Casbin combo

Payment Service

Description

Payment service will be used as a payment processor of every kind. Having said that there are multiple forms for this

  1. Payment Gateways a. Thawani b. Stripe
  1. Internal Accounts (Not for B2B) a. Bank Account b. Wallet

Technology

It will have providers registered to it. Each provider will be generally a parser which will map the response and request from our client touch-points to what external insurance partners understand and vice versa. Provider will come with its own set of configurations and rules Database will be relational database Postgres wherein we will store payment gateway transaction_id, order_reference_id, status, timestamps A webhook will be configured to propagate transaction status from payment service to order service and further down to notification service

Notification Service

Description

Notification Service is a service that handles all communications to the subscribers through below channels and is used for both transactional and marketing purpose

  1. SMS
  1. WhatsApp
  1. Email
  1. App

Technology

We will use Novu to handle opur notifications. Its opensource and already has lots of providers attached to it for each of above channels like Twilio, Clicksend, Amazon SES etc.

Logging Service

Description

Logging is an important aspect for any solution.

Technology

We will use ELK stack for our logging and storing of logs

Monitoring Service

Description

Monitoring Service is will help us in observability and alerting

Technology

We will use Prometheus with Grafana