PaymentSD1V01

supl.017.001.01

Supplementary data for payment message definitions.

Message Construction

Every ISO20022 message has at the highest level what we call ‘building blocks’. Because the message is constructed as immutable records, the association is by composition. Below you can see the relationship between the message and its constituent building blocks: For comparison, see the ISO20022 official specification

classDiagram
     direction LR
%% PaymentSD1V01 recursion level 0 with max 0
PaymentSD1V01 *-- "1..1" TransactionData1 : CardRemittanceInformation
  

Now, we will zero-in one-by-one on each of these building blocks.

CardRemittanceInformation building block

Structured card remittance information supplied in a payment. Card transaction information to be transferred. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% TransactionData1 recursion level 0 with max 1
class TransactionData1{
    CardBrand IsoMax35Text
}
TransactionData1 *-- "0..1" PlainCardData3 : CardData
TransactionData1 *-- "0..1" PointOfInteraction1 : PointOfInteraction
TransactionData1 *-- "0..1" CardPaymentTransactionDetails8 : TransactionDetails
TransactionData1 *-- "0..1" CashAccount24 : PrePaidAccount
%% PlainCardData3 recursion level 1 with max 1
class PlainCardData3{
    PAN IsoMin8Max28NumericText
    CardSequenceNumber IsoMin2Max3NumericText
    EffectiveDate IsoISOYearMonth
    ExpiryDate IsoISOYearMonth
}
%% PointOfInteraction1 recursion level 1 with max 1
class PointOfInteraction1{
    SystemName IsoMax70Text
    GroupIdentification IsoMax35Text
}
PointOfInteraction1 *-- "1..1" GenericIdentification32 : Identification
PointOfInteraction1 *-- "0..1" PointOfInteractionCapabilities1 : Capabilities
PointOfInteraction1 *-- "0..0" PointOfInteractionComponent1 : Component
%% CardPaymentTransactionDetails8 recursion level 1 with max 1
class CardPaymentTransactionDetails8{
    ICCRelatedData IsoMax1025Text
    MerchantCategoryCode IsoMin3Max4Text
    TransactionDateTime IsoISODateTime
    SaleReferenceNumber IsoMax35Text
    RePresentmentReason ExternalRePresentmentReason1Code
    AdditionalService CardPaymentServiceType2Code
    TransactionReference IsoMax35Text
}
CardPaymentTransactionDetails8 *-- "0..0" CardAmountAndCurrencyExchange1 : Amount
CardPaymentTransactionDetails8 *-- "0..1" PaymentContext3 : PaymentContext
%% CashAccount24 recursion level 1 with max 1
class CashAccount24{
    Currency ActiveOrHistoricCurrencyCode
    Name IsoMax70Text
}
CashAccount24 *-- "1..1" IAccountIdentification4Choice : Identification
CashAccount24 *-- "0..1" ICashAccountType2Choice : Type
  

TransactionData1 members

Member name Description Data Type / Multiplicity
CardBrand Brand name of the card. IsoMax35Text - Optional 0..1
CardData Card data associated with the card performing the transaction. PlainCardData3 - Optional 0..1
PointOfInteraction Point of interaction (POI) performing the transaction. PointOfInteraction1 - Optional 0..1
TransactionDetails Details of the transaction. CardPaymentTransactionDetails8 - Optional 0..1
PrePaidAccount PrePaid Account for funds transfer or loading. CashAccount24 - Optional 0..1

Extensibility and generalization considerations

To facilitate generalized design patterns in the system, the PaymentSD1V01 implementation follows a specific implementaiton pattern. First of all, PaymentSD1V01 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, PaymentSD1V01Document implements IOuterDocument. Because PaymentSD1V01 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type PaymentSD1V01.

classDiagram
    class IOuterRecord
    PaymentSD1V01 --|> IOuterRecord : Implements
    PaymentSD1V01Document --|> IOuterDocument~PaymentSD1V01~ : Implements
    class IOuterDocument~PaymentSD1V01~ {
        PaymentSD1V01 Message
     }
  

Document wrapper for serialization

The only real purpose PaymentSD1V01Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:supl.017.001.01’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using PaymentSD1V01.ToDocument() method. The returned PaymentSD1V01Document value will serialize correctly according to ISO 20022 standards.

classDiagram
    PaymentSD1V01Document *-- PaymentSD1V01 : Document
  

Sample of message format

This is an abbreviated version of what the message should look like.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:supl.017.001.01">
    <PmtSD1>
        <CardRmtInf>
            <!-- CardRemittanceInformation inner content -->
        </CardRmtInf>
    </PmtSD1>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_ZAIu0PwLEeGHDMP28rpT3g_-1117810318"
  name="PaymentSD1V01"
  definition="Supplementary data for payment message definitions."
  registrationStatus="Registered"
  messageSet="_QB0RcDy5EeO-tdK14jsZag"
  xmlTag="PmtSD1"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_ZAIu0fwLEeGHDMP28rpT3g_-1719162242"
    name="CardRemittanceInformation"
    definition="Structured card remittance information supplied in a payment."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="CardRmtInf"
    complexType="_Y-DEIfwLEeGHDMP28rpT3g_1761080314" />
  <messageDefinitionIdentifier
    businessArea="supl"
    messageFunctionality="017"
    flavour="001"
    version="01" />
</messageDefinition>

ISO Building Blocks

The following items are used as building blocks to construct this message.