Payment Scenarios, Data Entry Methods and Devices
During payment via the Unified Data Entry Solution, currently only dynamic (individual codes for one-time payment) code generation is possible. Depending on experience and business needs, the use of static codes (suitable for multiple payments) may be enabled in the future. Currently, field modification is only possible in a limited scope. Based on experience, field protection restrictions will be gradually relaxed. The field protection (editableFields), permitted payment method (QR, NFC, DEEPLINK) and applicable validity duration (expiryDateTimeoffset) values are determined by the mandatory payment scenario codes (purpose codes).
Application of payment scenarios
For purchases at physical points of sale, the IPPS payment scenario code can be applied; for web-based sales or payment interfaces, the IPEW code must be used.
For utility bill QR codes, the beneficiary may initiate the inclusion of the following codes: UBIL, COMT, TBIL, GOVT, INSU.
The expected payment scenario code for occasional commercial invoices and requests for payment is: IVPT. This code can also be applied when a payment scenario code with an expiry of at most 10 minutes would otherwise be required, but the Beneficiary wishes to specify an expiry period longer than 10 minutes within the (60-day) time interval assigned to this payment scenario. In this case, the remittance information should preferably be treated as a protected field.
For web-based sales or payment interfaces, the IPEW code must be used.
Application of data entry codes
The Aggregator applies five validity parameters (maximum values) in the various payment scenarios, defined in minutes. The beneficiary can decide within the interval on the offset parameter, i.e. the validity duration, taking into account the time required by the payer for reading the data, and supplementing and approving the instruction. Although the system could later be made capable of more nuanced specification of the expiry time, no particular business need for this has yet arisen, so it is more expedient to start the system's operation with this standardised parameterisation set by the Aggregator. The use of "Offset" values is regulated and controlled by the Sub-Aggregator. Payment scenarios - payment codes
| Payment scenario | Payment scenario code (Purpose code) |
|---|---|
| Purchase at physical point of sale | IPPS – Instant Payments at POS |
| Web purchase | IPEW - InstantPaymentsInECommerce |
| Utility bill (public administration, finance, telecommunications) | TBIL - TelecommunicationBill UBIL - Utilities (Electricity, Water/sewerage, Waste management, Gas) COMT - ConsumerThirdPartyConsolidatedPayment (bill collector) GOVT - GovernmentPayment (Magyar Posta Zrt., road toll) INSU - InsurancePremium (insurance premium) |
| Commercial invoice, request for payment based on occasional code | IVPT - InvoicePayment |
| Donation | IPDO - InvoicePayment |
Payment scenarios - permitted settings
| Payment scenario code | Expiry time (expiryDateTimeOffset) | Permitted methods (allowedModes) | Permitted devices (deviceType) | Editable fields (editableFields) | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| QR | NFC | DEEPLINK | POS (POS) | Cash register (CASHREGISTER) | Phone/Tablet/PDA (SMARTDEVICE) | Browser (BROWSER) | Messaging App (MESSAGINGAPP) | Paper (PAPER) | Amount editable? (isAmountEditable) | Remittance info editable? (isRemittanceInformationEditable) | Customer ID editable? (isCustomerIdEditable) | ||
| IPPS | Max. 10 minutes | X | X | X | X | X | X | ||||||
| IPEW | Max. 40 minutes | X | X | X | X | ||||||||
| TBIL UBIL COMT GOVT INSU | Max. 180 days (259,200 minutes) | X | X | X | X | X | |||||||
| IVPT | Max. 60 days (86,400 minutes) | X | X | X | X | X | X | ||||||
| IPDO | Max. 180 days (259,200 minutes) | X | X | X | X | X | X | X | |||||
In certain payment scenarios, the code request (create payment) message must be filled in differently. In every payment scenario, a payment scenario identifier (purpose code) must be applied; these codes are determined for each payment scenario. Filling in the scenario identifier is mandatory, as this code determines the special checks. It is the Sub-Aggregator's responsibility to ensure that Beneficiaries only fill in correct scenario identifier codes applicable to the given payment scenario, as the Aggregator does not validate these codes during message validation. Sub-Aggregators are expected to record in their contracts the payment scenario codes that can be used by the beneficiary, keeping in mind the need for clarity of invoice information prepared for the paying parties. Correct use of the payment scenario identifier codes is also important so that the payment service providers of the paying parties and beneficiaries, or the account information service providers engaged, can provide accurate statements to payers about their purchase transactions. In the case of commercial invoices and payment requests, the beneficiary can allow the payer to fill in the remittance information field by applying the appropriate field protection setting. Overriding the remittance information and amount will be possible in the context of person-to-person (P2P) payments, but the amount data only in later phases of development. For now, the system does not allow multiple payments to be fulfilled against a single generated code in the case of P2P payments (and only those) (it marks this as a duplicate payment, i.e. an error); the implementation of this will also only be possible in development phases following the system's go-live. The codes prescribed for use appear on the external code list of the ISO 20022 standard, so no "proprietary" (i.e. custom) code has been defined. If there is a need for new codes, they must be submitted to the authorised institution to be added to the ISO 20022 external codes list.