Payments

Connect financial accounting with payment workflows.

Infrarails provides financial infrastructure for applications that need to coordinate payment operations with internal ledger records.

A payment workflow may involve both an external financial provider and internal accounting transactions.

These components represent different aspects of the same business operation.

Payments and ledger transactions

A payment is a business operation involving the movement of funds or a payment instruction.

A ledger transaction records the corresponding financial effects within the accounting system.

These concepts should be distinguished.

For example, an external payment provider may accept a payment instruction while the internal ledger records its associated accounting state.

Payment architecture

A conceptual payment workflow consists of the following components:

flowchart TD
    A["Application"] --> B["Payment Workflow"]
    B --> C["External Financial Provider"]
    B --> D["Infrarails Ledger"]
    C --> E["Provider Status"]
    D --> F["Accounting Records"]
    E --> G["Reconciliation"]
    F --> G

The exact processing sequence depends on the payment type and provider integration.

Payment categories

Applications built on Infrarails may implement different payment workflows.

Internal payments

Internal payments move value between accounts maintained within the applicable accounting environment.

They can be represented through ledger transactions without necessarily requiring an external bank transfer.

SEPA payments

SEPA payments involve euro-denominated payment services operating under applicable SEPA schemes.

Where supported through an authorized provider, applications may coordinate SEPA payment instructions with corresponding ledger records.

SWIFT payments

International payment workflows may involve SWIFT messaging and external financial institutions.

Where supported, these workflows may require additional beneficiary, currency, settlement, and provider-specific information.

Payment processing

A payment workflow may involve several stages:

  1. Receive a payment request from the application.
  2. Validate the request and required information.
  3. Determine the applicable payment method.
  4. Calculate any relevant fees.
  5. Coordinate the operation with the appropriate provider.
  6. Record or update the associated ledger transaction.
  7. Track the provider and accounting outcomes.
  8. Reconcile the final operation.

The order and availability of these stages depend on the integration.

Payment statuses

External payment providers and the Infrarails ledger may use different status models.

For example, a provider might report that a payment instruction has been accepted while the ledger transaction remains in a processing state.

Applications should not assume that provider acceptance means final settlement.

Similarly, a completed internal accounting transaction does not automatically establish that an external bank transfer has settled.

Beneficiaries

Some payment workflows require beneficiary information.

Depending on the payment method, this may include:

  • Beneficiary name.
  • Account identifier or IBAN.
  • Bank identifier or BIC.
  • Country.
  • Address information.
  • Payment reference.

The required fields depend on the provider and payment scheme.

Currency conversion

Cross-currency payments may require an exchange rate or conversion instruction.

Such workflows can involve:

  • Source currency.
  • Destination currency.
  • Exchange rate.
  • Quoted amount.
  • Conversion fees.
  • Provider settlement requirements.

Foreign exchange behavior must be documented for the relevant payment integration.

Payment fees

Payment workflows may include charges such as:

  • Fixed payment fees.
  • Percentage-based fees.
  • Currency conversion charges.
  • Provider-specific fees.

These charges should be represented consistently within the applicable accounting workflow.

Reconciliation

Reconciliation compares external payment information with internal financial records.

This may involve matching:

  • Payment references.
  • Provider transaction identifiers.
  • Ledger transaction identifiers.
  • Amounts and currencies.
  • Processing statuses.
  • Settlement information.

Regulatory considerations

InfraRails is a technology infrastructure product.

Senmo Technologies Limited does not represent itself as a bank, electronic money institution, or payment institution.

Regulated payment services, where applicable, are provided by appropriately authorized third-party institutions.

Best practices

  • Separate provider status from ledger transaction status.
  • Preserve external and internal transaction identifiers.
  • Do not assume that an accepted payment is settled.
  • Handle asynchronous processing.
  • Use idempotency where supported.
  • Reconcile provider records against ledger records.
  • Protect beneficiary and payment information.
  • Validate fees and currency conversion before executing financial operations.

Next steps

Continue with Fees to understand how financial charges can be calculated and represented within InfraRails.


Did this page help you?