CreditTransferRequest

	  dictionary CreditTransferRequest {
	  sequence<DOMString> requiredResponseFields;
	  sequence<DOMString> supportedNetworks;
	  sequence<DOMString> supportedCountries;
	    
          required DOMString payeeIBAN;
	  DOMString payeeName;
	  DOMString payeeAddress;
	  required DOMString payeeBIC;
	  DOMString payeeIdentificationCode;

	  DOMString payeePaymentIdentificationHumanReadable;
          required DOMString payeePaymentIdentificationMachineReadable;

	  DOMString sellerName;
	  DOMString sellerIdentificationCode;
	    
	  required DOMString purposeCode;
	  DOMString categoryPurposeCode;
	    
	  DOMString preferredProcessingDate;
	  DOMString notificationURL;
	  };
	

The CreditTransferRequest dictionary contains the following fields:

requiredResponseFields

Contains the list of fields that the Payment App must attempt to return, if this requirements cannot be met, e.g., the payment instrument must fail as this is a push payment.

The above field is required, but this can result in failed payments after 'Authorise' clicked. Should we have a better modelling (e.g. using subclasses) to allow for a more fine-grained matching of apps to requests? Does the PMI specification need to support this?

supportedNetworks

The supportedNetworks field contains a sequence of identifiers for credit transfer networks that the merchant accepts. This field is optional. If a value is not provided then the merchant accepts credit transfers from any credit transfer network. Note: The Web Payments Working Group is still discussing whether and how to maintain a database of supported network identifiers.

supportedCountries

The supportedCountries field contains a sequence of [[!CLDR]] identifiers of countries from which the merchant accepts credit transfers. This field is optional. If a value is not provided then the merchant accepts credit transfers from any country.

payeeIBAN

This field indicates the account number of the payee (the merchant) that will be used for the credit transfer. This will typically be an IBAN number, or a domestic account number for those countries that do not use IBAN.

payeeBIC

The Bank code of the payee that should be used along the “payeeIBAN” in order to send the Credit Transfer.

payeeName

The name of the payee known to the bank that holds the account describe by “payeeIBAN”.

payeeAddress

The address of the payee known by the bank that holds the account describe by “payeeIBAN”.

payeeIdentificationCode

An identification code provided by the payee.

payeePaymentIdentificationHumanReadable

Human-readable remittance information explaining to the payer what is being paid for.

payeePaymentIdentificationMachineReadable

Remittance information used for automatic matching upon receipt of the credit transfer.

sellerName

The name of a person or company in relation to whom a Beneficiary receives a payment.

sellerIdentificationCode

A code related to “sellerName”.

purposeCode

The purpose of the credit transfer is the underlying reason for the credit transfer transaction, i.e. information on the nature of such transaction. Values are drawn from ISO20022 External Code Sets.

categoryPurposeCode

The category purpose of the credit transfer is information on the high level nature of transaction. Values are drawn from ISO20022 External Code Sets.

preferredProcessingDate

The merchant's preferred processing date. See also: SelectedProcessingDate in the CreditTransferResponse.

Date format?

notificationURL

An end point for payment status updates. This specification does not define how such endpoints will work.

CreditTransferResponse

The CreditTransferResponse message means that a message has been submitted to the Payee's Bank, not that funds transfer has occurred. The merchant should wait for notification from its Bank that the payment has cleared.

 
	  dictionary CreditTransferResponse {
	  required	DOMString selectedProcessingDate;
	  required	DOMString payerPaymentIdentification;
	  required	DOMString payerBIC;
	  required	DOMString selectedNetwork;
	  DOMString  	payerIdentificationCode;
	  DOMString     payerName;
	  DOMString     buyerIdentificationCode;
	  DOMString     buyerName;
	  };
	

The CreditTransferResponse dictionary contains the following fields:

selectedProcessingDate

The date for commencing the execution of the payment request. This date may be different from that requested by the Payee, either because of a business rule (e.g., non business day, or a preference from the payee to defer payment

payerPaymentIdentification

A unique identifier for a given payer each Credit Transfer Transaction presented to the payer Bank. This number will be transmitted in the entire process of the handling of the credit transfer transactions from acceptance until the finality of the transaction. It must be returned in any exception handling process-step by any party involved. The payer cannot request for any other referencing information to be returned to him, in order to identify a credit transfer. The payer must define the internal structure of this reference; it can only be expected to be meaningful to the payer.

payerBIC

The BIC code of the bank which send the Credit Transfer

selectedNetwork

The network used by the originator to send the credit transfer

payerIdentificationCode

A code supplied by the payer.

payerName

The name of the payer.

buyerIdentificationCode

The buyer reference. The buyer may be a 3rd party to the payer, if the payer is paying on behalf of another party.

buyerName

The buyer name. The buyer may be a 3rd party to the payer. If the payer is paying on behalf of another party.

The above four fields return information about the payer and buyer, are there any privacy implications for these?

CreditTransferRequest Fields

CreditTransferResponse Fields

Sources

• Customer to Bank Credit Transfer Initiation (DS-01) specification from SEPA Credit Transfer Rulebook Version 8.1. The SEPA Rulebook may impose additional implementation restrictions (e.g., number of characters) not defined in the current specification.