Pocessing systems are using manually crafted application relays to handle card processing business rules. Being defined by business analysts these rules are fallen down to engineering teams informally. Approach we provide pushes card processing to solid background in a form of domain specific language common for all card plans analytics departments.
Having compact language we can formally build various translators for particular customers and existing processing systems. At the same time we provide reference back-end Erlang system implementation for transactions processing. Also DSL gives us a natural and easy verification strategies and compactifications.
This language could be easily extended to other domain areas like internet payment processing, shopping mall bonus programs, mobile operators tariff plans.
The aim is to create small and compact language for payment transaction processing. Underlying instrumentation code should be KVS layer for storing transaction chains but naturally should be extended to different backends like Java, PL/SQL and other languages currently involved in banking card processing. We have several criteria to satisfy:
| English | Self-explanatory |
| Fasten | Time-to-market |
| Optimized | Minimal Back-end Operations |
| Verified | No regular bugs. Only business logic. |
| Taxonomy | Sane structure for extensions |
User Creation:
Process Transaction:
Notifying:
Programs are tariff programs, set of rules that we plug to transaction processing. It feels like set of filters triggered each time we fire money movements on account with a given card defenition.
Example:
Programs are stored in its own space.
Top level tariffs of billing rules are pluggable slangs that share some common part of the languages. These common part we will call language forms.
Enterprise Tree handles clients, accounts, transactions, programs, events. Programs could be assigned to each node and fires atomatically on access.
External service has its own endpoints, and could be addressed/mounted? to local system.
Transactions are stored per each client’s account.
Deposit program forms ususally provides such attributes of account as duration, rate, withdraw locking, charge limits, fee options and other deposit specific options. Deposit forms usually have "deposit" account name.
Credit programs forms mainly provide transaction filtering and other default account name "credit".