Payment Initiation Sources
This section will describe ways that payments can be initiated. For each way, testing suggestions will be given that apply specifically for that type. For general testing suggestions that apply to payments overall, see Other payment related functionalities section.
Internet bank
Payments initiated from the user interface that the bank provides for its customers.
Types of payments usually include: Internal payments, SEPA payments, Instant payments, Swift payments, Target2 payments, and Salary batch payments.
Users can initiate these payments via UI forms or by importing pain.001
XML files (more common for corporate users). Internet banks often support regular/scheduled payments (e.g., once per month).
Most internet banks are accessible via browsers and mobile apps (Android/iOS). Features may differ across platforms, so testing should cover both.
Testing suggestions:
- Verify payment status updates correctly (accepted, executed, rejected, etc.).
- Confirm that customer-entered details appear correctly in statements.
- Test all payment forms and payment types.
- Use min/max symbols in form fields.
Pain.001 files
Pain.001 (payment initiation) files are XML files used to initiate payments, typically for corporate customers, but sometimes also private ones. They allow users to upload large batches (hundreds or thousands) of payments.
Files can be marked as Salary payments, Pension payments, or processed with Batch booking.
Batch booking ensures all payments succeed together, or none are processed.
In account statements:
- Regular bulk → all payments appear individually.
- Salary batch → appears as one combined entry.
Each bank supports different Pain.001 fields.
Here is a generic example with a salary batch of 0.10 + 0.11 EUR payments: pain001 - message example.xml
Testing suggestions:
- Import payments using all allowed Pain.001 fields with min/max symbols.
- Test different values so results are SEPA/Instant/SWIFT/Internal/Target2.
- Test Salary bulk with mixed results (some succeed, some fail, mixed payment types).
- Use fields in Pain.001 that aren’t available in UI forms.
- Upload invalid files and confirm proper error messages.
FIDAVISTA files
Similar to Pain.001 files, mostly used in Latvian banks.
Logic is nearly identical, so test if supported by the bank.
Bank employee
Payments initiated by a bank employee, usually not via internet bank but directly in the bank system or specialized UI.
Scenarios include:
- Customer requests the bank to create a payment.
- Payment created due to technical issues.
- Manual return of payment to customer.
- Payment from technical accounts not owned by customers.
Depending on the bank, systems may be modern UIs or legacy systems requiring special knowledge.
They often support regular payments (daily, monthly, etc.).
Testing suggestions:
- Employee systems may allow fields not possible in customer internet bank.
- Always include employee systems in testing when payment flow changes.
Regular payments
As noted above, several initiation methods support automatic recurring payments (daily, monthly, etc.).
Testing suggestions:
- Verify that previously created regular payments continue to work after system changes.
- Check that changes to payment forms don’t break existing regular payments.
Incoming payments
Incoming payments are recorded in the bank system like outgoing ones, but not created inside it.
All payment types (SEPA, Instant, etc.) can arrive as incoming payments.
Testing suggestions:
- Cover all allowed payment fields in messages.
- Ensure optional fields (unused in outgoing) are still supported when incoming.
- Since incoming can’t be initiated directly, test with XML injections into system queues.
PSD2
PSD2 (Payment Services Directive 2) is a European directive regulating payment services via third parties.
Example:
- An Internet Store initiates a payment request via the bank.
- Customer authenticates with their bank.
- Bank confirms to the store once successful.
This supports SEPA and Instant payments (depending on bank).
For SEPA, funds may arrive days later even though confirmation is instant.