cdf3 Faq
cdf3 Faq
cdf3 Faq
If you are a Processor or Issuer sending files TO MasterCard, then you are an INBOUND
customer.
If you are a Corporation or a third-party host for corporations, receiving files FROM
MasterCard, then you are an OUTBOUND customer.
Question: How does the CDF3 system work? When will the Smart Data files be
distributed?
Answer: The MasterCard Provider system runs 20 hours per day, 6 days per week
(subject to change with limited notice). All inbound files are queued immediately for
processing. Unless a file is received during an outage window, processing of the file will
start no longer than 4 hours after receipt. In most cases, the outbound corporation files are
distributed as soon as they are available. This means that the delivery of an outbound file
is dependant almost entirely on the arrival of the source file at MasterCard, not on a
MasterCard batch schedule.
The second thing to do is to identify which data elements are applicable to the system
which is sending data to MasterCard. If there are single data elements or whole groups of
data elements that cannot be supplied then they can simply be ignored. Because the XML
tags will not be sent for elements that cannot be supplied, there is no need to be
concerned with the sending of default values in those fields.
name= The name of the tag in the XML file. In this instance, the name of
the tag is BillingType.
type= The data type restrictions placed on this field. In other words, the
acceptable types and values for this tag. In this instance the data type is
BillingType.
minOccurs= The minimum number of times a tag can occur.
maxOccurs= The maximum number of times a tag can occur.
Example 1:
<xs:element name="BillingType" type="BillingType" minOccurs="1"
maxOccurs="1"></xs:element>
This notation implies that the tag BillingType is required. There can be one and
only one entry for this tag.
Example 2:
<xs:element name="ProcessingCorporateAccount" type="Id19Type"
minOccurs="0" maxOccurs="1"></xs:element>
This notation implies that the tag ProcessingCorporateAccount is not required.
There can be zero to one entry for this tag.
Question: How do I determine the data type and acceptable value for each tag
(field)?
Answer: Each tag in the XML Schema Document (CDFFileTransmission.xsd)
contains a type= attribute. This attribute is used to detetermine not only the data type and
size, but in some instances, acceptable values.
Example 1:
<xs:element name="AccountNumber" type="Id19Type" minOccurs="0"
maxOccurs="1"></xs:element>
The AccountNumber tag has a type of Id19Type. You will need to find the
definition of this type in the CDFFileTransmission.xsd file.
<xs:simpleType name="Id19Type">
<xs:restriction base="xs:token">
<xs:minLength value="1"></xs:minLength>
<xs:maxLength value="19"></xs:maxLength>
</xs:restriction>
</xs:simpleType>
This Id19Type is a simple data type. In this example, the AccountNumber can
have a length between 1 and 19 characters inclusive.
Example 2:
<xs:element name="TransactionDate" type="MasterCardDateType"
minOccurs="1" maxOccurs="1"></xs:element>
<xs:simpleType name="MasterCardDateType">
<xs:restriction base="xs:date"></xs:restriction>
</xs:simpleType>
Example 3:
<xs:element name="DebitOrCreditIndicator" type="SignCodeType"
minOccurs="1" maxOccurs="1"></xs:element>
The DebitOrCreditIndicator tag has a type of SignCodeType. You will need to
find the definition of this type in the CDFFileTransmission.xsd file.
<xs:simpleType name="SignCodeType">
<xs:restriction base="xs:token">
<xs:enumeration value="C"></xs:enumeration>
<xs:enumeration value="D"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
Example 4:
<xs:element name="AmountInOriginalCurrency" type="CurrencyAmountType"
minOccurs="1" maxOccurs="1"></xs:element
<xs:complexType name="CurrencyAmountType">
<xs:simpleContent>
<xs:extension base="CurrencyType">
<xs:attribute name="CurrencyCode"
type="CurrencyCodeType"
use="required"></xs:attribute>
<xs:attribute name="CurrencyExponent"
type="CurrencyExponentType"
use="required"></xs:attribute>
<xs:attribute name="CurrencySign"
type="SignCodeType"
use="required"></xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
The above example represents a debit amount in the 840 currency of 109.38.
Question: Do I put in the decimal (.) character in amount fields?
Answer: No, the CDF v3.0 XML Schema Document (CDFFileTransmission.xsd)
states that no decimals are to be placed in amount fields. The concept of an exponent is
used in the CDF v3.0 document.
Example:
<TotalnumofAccounts>10</TotalnumofAccounts>
Examples of items that will not pass validation are: a) missing required fields b)
incorrect data length c) incorrect data type d) incorrect data format (invalid date format)
e) tags that are misspelled or have incorrect character case f) etc
MasterCard International strongly recommends all CDF v3.0 files be validated against
the schema before they are sent to MasterCard International. This will make it much
easier on the data provider to fix data errors before they are sent to MasterCard
International.
Question: XML does not allow certain characters. What do I do?
Answer: XML control characters need to be sent as indicated below. For example,
if you have a merchant named Steve & Jose Bookstore you would need to enter this in
the XML file as Steve & Jose Bookstore.
Character Reference
& &
< <
> >
" "
' '
Question: May we change the XML version or encoding format in the CDF 3
file?
Answer: No, the first two lines of the CDF 3 file must be sent as identified in the
Sample File.
Question: The sequence numbering in the sample file does not look sequential.
Does it need to be?
Answer: Sequencing is used for error reporting and each instance should be unique
throughout the file.The sequence number of the hierarchyrecordheader may be a
continuation of the Sequence Number in the Financial Record Header.
Question: How do I handle fields, such as the Account Number, that expanded
from a 16 position numeric field to a 19 positions alphanumeric field?
Answer: If the field was established in GDR prior to CDFv3, the field was decimal
aligned and zero filled. The field is now defined as alphanumeric, meaning that it can
handle both numeric and alpha characters, so, in order to match the field in the database,
the first 16 position must be numeric and the remaining three characters must be spaces.
If the field is new to the database, the field can be configured anyway you wish. But,
consistency is the key ingredient.
Default Values:
The following fields have default values in the Schema, and may be sent as empty tags as
indicated below:
<AcceptanceBrandIdCode></AcceptanceBrandIdCode> = MCC
<CorporateProduct></CorporateProduct> = MCO
<AdjustmentReasonCode></AdjustmentReasonCode> =--