Add a New Country

This document describes the necessary steps to configure a new country in the CoreWallet.

Configure wallet ProductConfiguration

The wallet ProductConfiguration defines what business processes are allowed in the wallet - the new country must be configured here as well. Please note that typically each product has its own dedicated ProductConfiguration, the changes should of course only be made there.

In com.trimplement.wallet.server.wallet.impl.product.dom.DefaultProductConfigurationImpl.createDefaultProductConfiguation() we add the currency to the supported country codes:

setSupportedCountryCodes(EnumSet.of(CountryCode.CH));

We should define what initial wallet accounts will be created when a new wallet is created in that country:

getInitialWalletAccountCurrenciesByCountryCode().put(CountryCode.CH, Arrays.asList(CHF));

We should define the default payment MCCs for the country:

for (final String currency : getSupportedWalletAccountCurrencies()) {
    getPaymentCategoryCodeByCountryCurrency().put(new CountryCurrencyKey(CountryCode.CH, currency), mccByPaymentType);
}

We should define in what subsidiary new wallets will be created in that country:

getSubsidiaryIdByCountryCode().put(CountryCode.CH, SUBSIDIARY_FOR_CH);

If P2P-vouchers are to be supported, we should add the country in com.trimplement.wallet.server.wallet.impl.product.dom.DefaultProductConfigurationImpl.voucherConfiguration.

If there are non-default Email configurations, we should configure them in com.trimplement.wallet.server.wallet.impl.product.dom.DefaultProductConfigurationImpl.systemEmailMapping.

If there are non-default SMS configurations, we should configure them in com.trimplement.wallet.server.wallet.impl.product.dom.DefaultProductConfigurationImpl.systemSmsMapping.

Configure payment methods and business contract routes

If required, applicable payment methods and business contract routes need to be configured by SQL.

Configure required/verifiable user data for this country and user verification levels


Required and verifiable user data for the given country, subsidiary id and user verification level can be configured by SQL, see user_data_config table. Example sql:

INSERT INTO `user_data_config` (`COUNTRY`, `CREATION_DATE`, `END_DATE`, `FIELD_GROUP`, `REQUIRED`, `START_DATE`, `SUBSIDIARY_ID`, `VERIFIABLE`, `VERIFICATION_LEVEL`)
VALUES ('CH', UTC_TIMESTAMP(), NULL, 'EMAIL', 1, UTC_TIMESTAMP(), 1, 1, 'EMONEY_BASIC');

Configure wallet verification process

WalletVerificationProcessConfiguration defines configuration for wallet data verification processes, see initConfiguration() method.

The following configuration parameters can be defined per country resp. currency:

For bank account verification:

  • min and max amounts and amount scale for bank account verification process per currency
    payment instrument verification process type per currency
    default account currency per country
  • default bank transfer statement
  • max allowed processes per user (to avoid that user starts many verification processes to get money from the system)

The following configuration parameters are valid for all countries.

For email verification:

  • whether email verification must be started right after registration
  • whether email verification must be started right after phone number verification

For phone number verification:

  • whether phone number verification must be started right after registration
  • whether phone number verification must be started right after email verification

Configure permitted actions per country and verification level

If needed, configure permitted actions per country and user verification level. If country or user verification level is set to NULL configuration is valid for all countries / all levels.

Currently permitted actions can be configured by SQL, see wallet_action_permission_config table. Example SQL:

INSERT INTO `wallet_action_permission_config`
(`can_fund`, `can_purchase`, `can_receive_payment`, `can_send_payment`, `can_trade`, `can_withdraw`, `country_code`, `creation_datetime`, `description`, `subsidiary_id`, `user_verification_level`, `wallet_type`)
VALUES
(1, 0, 1, 1, 1, 1, NULL, UTC_TIMESTAMP(), 'Permitted actions for verification level basic, all countries', 1, 'EMONEY_BASIC', NULL);

Configure address validators and compatible address countries

If needed, configure address validators per country and compatible address countries. Compatible countries A - B means: a user in country A can add address in country B.

See user.impl.DefaultAddressService bean in Spring XML configuration.

Add an entry to addressValidators, if a specific address validator implementation is available. E.g. <entry key="DE" value-ref="product.impl.GermanUserAddressValidator" /> (No specific address validator is yet available per country, it’s just an example)

Add an entry to compatibleCountries, e.g. <entry key="DE" value="DE" /> or <entry key="DE" value="ALL" /> or <entry key="DE" value="DE, CH" />

Configure SMS templates

If needed, configure SMS templates, currently by SQL. If you want that an SMS template is shared between different countries (same language), let country value be null.

INSERT INTO `mpt_sms_template`
(`country`, `language`, `sms_id`, `template_text`)
VALUES
(‘DE’, 'DE', 'MobilePhoneValidation', 'Ihre CoreWallet Mobile PIN lautet: #code#');

SmsId MobilePhoneValidation needs then to be configured in the product specific SMS mapping (see configuration of wallet ProductConfiguration above).

Configure new language for SMS and emails

If a new language shall be supported for emails and SMS, then according email and SMS templates should be created and the following configurations shall be adapted/extended.