Technicalmanual

Duepaymentin XMLformat

Version2.0

Technicalmanual– Due payment inXML format

Contents

1.INTRODUCTION...... FEIL! BOKMERKEERIKKEDEFINERT.

1.1ABOUT THISDOCUMENT...... FEIL!BOKMERKEERIKKE DEFINERT.

1.2TARGETGROUP...... FEIL!BOKMERKEERIKKE DEFINERT.

1.3LIMITATIONS...... 3

2FUNCTIONALITY...... 4

2.1DESCRIPTION...... FEIL!BOKMERKEERIKKE DEFINERT.

2.2TRANSMISSION...... FEIL!BOKMERKEERIKKE DEFINERT.

2.3ASSIGNMENT...... FEIL!BOKMERKEERIKKE DEFINERT.

2.4TRANSACTIONLEVEL...... 4

2.5XMLSTANDARD...... 4

2.6FLOWCHART...... 4

2.7TABLES USED INTHISDOCUMENT...... 7

3SPECIFICATIONFORINCOMINGTRANSMISSION...... 8

3.1TRANSMISSIONLEVEL...... 8

3.2ASSIGNMENTLEVEL ...... 9

3.3ATTACHMENTS...... FEIL! BOKMERKEERIKKE DEFINERT.

3.3.1Incomingtransmission-duepaymentfilestructure(example1)...... 9

3.3.2Incomingtransmission-duepaymentfilestructure(example2)...... 11

3.4XML Schema …………………...... 11

4OVERVIEWOVERMESSAGESTHATCANBESENTIN ANINCOMINGTRANSMISSION....13

4.1PAYMENTRQ...... 13

4.1.1Scenarioforexchangeofduepayment(PaymentAdd)...... 14

5SPECIFICATIONSFOROUTGOINGTRANSMISSIONS(TRANSMISSIONRECEIPT)...... 15

5.1TRANMSISSIONLEVEL...... 15

5.2ASSIGNMENTLEVEL ...... 16

5.3ATTACHMENTS...... FEIL! BOKMERKEERIKKE DEFINERT.

5.3.1Outgoingtransmissions-Exampleof 1stlevelreceipt,transmissiondenied

(524= Errorin ServiceProviderFileDate)...... 18

5.3.2Outgoingtransmission-Exampleof2nd levelreceipt,assignmentdenied

(509=InvalidContentProviderFileReference)...... 19

5.3.3Outgoing transmissin -Exampleof2nd levelreceipt,1denied transaction

(503=Duepaymentwithoutactiveagreement)...... 20

5.4XML Schema ...... 20

6OVERVIEWOVERMESSAGESTHATCANBESENTIN ANOUTGOINGTRANSMISSION...22

6.11STLEVEL2NDLEVELRECEIPT...... 22

6.1.1Scenariofor1stlevel2ndlevelreceipt...... 22

6.1.2Explanationfor1stlevelreceipt...... 22

6.1.3Explanationfor2nd levelreceipt...... 23

6.1.4Reasonfordenied1stlevelreceipt...... 24

6.1.5Reasonfordenied2nd levelreceipt...... 24

6.2PAYMENTRS...... 26

6.2.1Reasonfordenialontransactionlevel...... 27

7AMENDMENTLOGFOR THISMANUAL...... 28

1Introduction

1.1 Aboutthisdocument

Thisdocumenthasbeenmadetoshowwhichfilestructurestheissuer mustusewhen communicatingwithNETSwhenhandlingduepayments.Whenusing thisdocument the issuer/partnerwill beable tosendtransmissions toNETS andreceive transmissionsfromNETS.

1.2 Targetgroup

Thisdocumentismeant for issuer/eBillinghotel andotherpartnersinvolvedinimplementinglocal invoicestorage.

1.3 Limitations

Thisdocumentdescribestheformat for incomingandoutgoing transmissionsbetweenNETS and eBillinghotel/issuer whenusinglocal invoicestorage.

2Functionality

2.1 Description

TheeBillinghotel/issuer sendsatransmissiontoNETSthat consistsof3levels.The3levels identifytheeBillinghotel, issuer andwhich transactionsissuerwantstocarryout.

NETS’ outgoingtransmissionsconsist of thesameitemsastheincoming transmissions.The outgoingtransmissions will containatransmissionlevel,anassignmentlevel anda transaction level. TheeBillinghotel/issuer mustuse thistransmission tocheck that theentireincoming transmissionwasprocessedinNETS, andifnot, correct theerrors.

2.2 Transmission

A transmissionisthefirst level and theremayonlybeoneoftheseper file.Thetransmission level must alwaysbefilledin.

2.3 Assignment

Theremaybeoneor moreassignment levelsper transmissionlevel,but mostlikely just oneper issuer. Anassignment identifiesaset oftransactionsbelonging tooneissuer.Theassignment level must alwaysbefilledin.

2.4 Transactionlevel

Thetransactionlevel containsinformationabouteachtransaction. There maybefrom1tox amount ofdetailedtransactionsonthislevel.

2.5 XML Standard

Theformat for incomingandoutgoing transmissionsforlocal invoicestorage isXML1.0.The specificationsforXML1.0arefoundat

Beawareofthat:

•theXMLstandardiscasesensitive,that is;lowercaselettersandcapitol letter must beused asdirectedinthisdocument.

2.6 Flowchart

Inthelocal invoicestoragethereare3possiblescenariosforgeneratingduepaymentsandwho sends theduepayment toNETS. Thesearedescribedin thefollowingdrawings.

4.Internetbankapplication fetches

URLwhich points toinvoicedetails

5. Nets-server returns signed URL

Nets

2.Netssends receipt to eBillingHotel

1.eBillingHotelsends duepaymentfiletoNets

Internetbank

6.Useris re-routed totheURL’s content (invoicedetails)

7.URL

link

eBillingHotel

3.Userwantstosee the invoicedetails

User

Thisflowchartshows theeBillinghotelastheonlyparty involvedin theduepaymentprocess. In thisscenario, theeBillinghotelgeneratestheduepayment fileandsends theduepaymentsto NetsinXML-format.

5.Internetbankapplication fetches

URLwhich points toinvoicedetails

6. Nets-server returns signed URL

Nets

3.Netssends receipt to eBillingHotel

2.eBillingHotelsends due payment file to Nets

Nettbank

7.Useris re-routed totheURL’s content (invoicedetails)

8.URL

link

eBillingHotel

4.Userwantstoseetheinvoicedetails

Forbruker

Issuer

1.Issuer sends invoiceinfoto eBillingHotel

Thisflowchartshowsascenariowhere theeBillinghotelreceives thepayment informationfrom anissuer andtheeBillinghotel sendstheduepayment filetoNets.

Diagram3

4.Internetbankapplication fetches

URLwhich points toinvoicedetails

Nets

5. Nets-server returns signed URL

1.Issuer sendsdue payment file to Nets

2.Netssends receipt to issuer

Nettbank

6.Useris re-routed toURL’s content (invoicedetails)

7.Link

Utsteder

3.Userwantstoseetheinvoicedetails

Forbruker

Thisflowchartshowsascenariowhereissuer is theonlyparty involvedin theduepayment process. Issuergenerates theduepaymentand sendsit toNETS.

2.7 Tablesusedin thisdocument

Thetablesusedtodescribe thetransmission, assignmentanddetail levelsaredescribedas follows:

TAG / DESCRIPTION / FORMAT
Describesthetag
usedinXML / Describesthepurposeof thetag. / Describestheformat ofthe tag.

3Specificationsforincomingtransmission

3.1 Transmissionlevel

Thetransmissionlevel isthetoplevel inafile. It stateswhicheBillinghotel/issuer thatsendsthe detail transactions.

TAG / BESKRIVELSE / FORMAT
?xml version="1.0" encoding="ISO-
8859-1"?> / Thiscodemust beat thetopofthefileto ensurecorrect formatting/character set in
theXMLfile. / -
Message> / Message marksthestart andendofthe
message. / -
Request / Headerinformationabout theinvoice. / -
FromInfo> / Informationunder FromInfostateswhosent thefile. / -
ServiceProviderId> / Datafieldthat statesthesenderof thefile. Uniquesender ID intheeBillinghotel.
ForexampleNOR123456789-1 / •Alfanumerical,14 characters
•Format =NOR
uniqueID withNETS-
1
ServiceProvider
FileDate> / Datafieldthat stateswhen thefilewassent. / •Nospace
•Noperiod
•Format = DDMMYYYY
ServiceProviderFile
Reference / Datafieldthat statesthefile’sunique reference.
Thefieldwill becheckedforduplicatesat
NETS.
Forexample: 20020615001 / •Numerical,11 characters
•Format: YYYYMMDDXXX
•All datesgreaterthan
10daysaheador backintimewill be
denied.
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXX =uniqueserial number,ascending from001
ServiceProvider
FileStatus> / Datafieldthat statesifthisisatest transmissionor aproductiontransmission. / •Numerical,1 characters
•Format =
1= Production
0=Test
ToInfo> / InformationunderToInfostateswho thefile
isfor. / -
ServiceProviderId> / Stateswhoshall receive thefile. / •Always8080

3.2 Assignment level

Theassignmentlevel containsinformationaboutwhichissuer that issending thetransaction details. Thefollowingtableshowswhichelementsthatarerequiredtodefineanassignment.

TAG / BESKRIVELSE / FORMAT
ContentProviderRQ / Theremaybeseveral issuersinonefile. Everyassignment isdefinedbya
ContentProviderRQperissuer. / -
ContentProviderInfo / Informationaboutissuer that sent the information. / -
ContentProviderId> / Issuer’suniqueissuer IDwithNETS.For example:NOR123456789-1. / •Alfanumerical,14 characters
•Format =NORunique
ID withNETS>-1
ContentProvider
Date> / Statesthedatetheassignment was generated. / •Nospace
•Noperiod
•Format =DDMMYYYY
ContentProviderFile
Reference / Datafieldthat statestheassignments uniquereference.
Thefieldwill becheckedforduplicateswith
NETS.
Forexample: 200206150001 / •Numerical,12 characters
•Format: YYYYMMDDXXXX
•All datesgreaterthan
10daysaheadorback in timewill bedenied.
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXXX = uniqueserial number,ascending from0001

3.3 Attachments

3.3.1 Incoming transmission –duepayment filestructure(example 1)

<?xmlversion="1.0"encoding="ISO-8859-1"?>

<Message>

<Request>

<FromInfo>

<ServiceProviderId>

<![CDATA[]]>

</ServiceProviderId>

<ServiceProviderFileDate>

<![CDATA[]]>

</ServiceProviderFileDate>

<ServiceProviderFileReference>

<![CDATA[]]>

</ServiceProviderFileReference>

ServiceProviderFileStatus

<![CDATA[]]>

</ServiceProviderFileStatus

</FromInfo>

<ToInfo>

<ServiceProviderId>

<![CDATA[]]>

</ServiceProviderId>

</ToInfo>

</Request>

ContentProviderRQ>

ContentProviderInfo>

<ContentProviderId>

<![CDATA[]]>

</ContentProviderId

ContentProviderDate>

<![CDATA[]]>

</ContentProviderDate

<ContentProviderFileReference>

<![CDATA[]]>

</ContentProviderFileReference>

</ContentProviderInfo>

<PaymentRQ>

<PaymentRQInfo>

<ProductId>

<![CDATA[]]>

</ProductId>

<NumberOfTransactions>

<![CDATA[]]>

</NumberOfTransactions>

</PaymentRQInfo>

PaymentAdd>

<Reference>

<![CDATA[]]>

</Reference>

CustomerAgreementReference

<![CDATA[]]>

</CustomerAgreementReference>

<Kid>

<![CDATA[]]>

</Kid>

<DueDate>

<![CDATA[]]>

</DueDate>

<AmountDue>

<![CDATA[]]>

</AmountDue>

<MinimumAmountDue>

<![CDATA[]]>

</MinimumAmountDue>

<CreditAccountNumber>

<![CDATA[]]>

</CreditAccountNumber>

<BrandName>

<![CDATA[]]>

</BrandName>

PaymentType>

<![CDATA[]]>

</PaymentType>

<DetailReference>

<![CDATA[]]>

</DetailReference>

</PaymentAdd>

</PaymentRQ>

</ContentProviderRQ>

</Message>

3.3.2 Incoming transmission –duepayment filestructure(example 2)

3.4 XML Schema

<?xml version="1.0" encoding="UTF-8"?>

xs:schema xmlns:xs=" elementFormDefault="qualified">

<!--

This xsd reflects the true datatype for all elements.

Due to requirements for sending fine grained error messages a more lenient

version is used when validating received xml from external hotels.

Content providers, developers using NETS services and testers of new customers,

are encouraged to use this (strict) xsd for validation before sending content to NETS.

-->

xs:element name="Message">

xs:complexType

xs:sequence

xs:element ref="Request"/>

xs:element ref="ContentProviderRQ" maxOccurs="unbounded"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="Request">

xs:complexType

xs:sequence

xs:element ref="FromInfo"/>

xs:element ref="ToInfo"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="FromInfo">

xs:complexType

xs:complexContent

xs:extension base="ServiceProviderId">

xs:sequence

xs:element ref="ServiceProviderFileDate"/>

xs:element ref="ServiceProviderFileReference"/>

xs:element ref="ServiceProviderFileStatus"/>

</xs:sequence

</xs:extension

</xs:complexContent

</xs:complexType

</xs:element

xs:element name="ServiceProviderFileDate" type="xs:integer"/>

xs:element name="ServiceProviderFileReference" type="xs:integer"/>

xs:element name="ServiceProviderFileStatus" type="xs:integer"/>

xs:element name="ToInfo" type="ServiceProviderId"/>

xs:element name="ContentProviderRQ">

xs:complexType

xs:sequence

xs:element ref="ContentProviderInfo"/>

xs:element ref="PaymentRQ"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="ContentProviderInfo">

xs:complexType

xs:sequence

xs:element ref="ContentProviderId"/>

xs:element ref="ContentProviderDate"/>

xs:element ref="ContentProviderFileReference"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="ContentProviderId" type="xs:NCName"/>

xs:element name="ContentProviderDate" type="xs:integer"/>

xs:element name="ContentProviderFileReference" type="xs:integer"/>

xs:element name="PaymentRQ">

xs:complexType

xs:sequence

xs:element ref="PaymentRQInfo"/>

xs:element ref="PaymentAdd" maxOccurs="unbounded"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="PaymentRQInfo">

xs:complexType

xs:sequence

xs:element ref="ProductId"/>

xs:element ref="NumberOfTransactions"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="ProductId" type="xs:integer"/>

xs:element name="NumberOfTransactions" type="xs:integer"/>

xs:element name="PaymentAdd">

xs:complexType

xs:sequence

xs:element ref="Reference"/>

xs:choice minOccurs="1">

xs:element ref="EfakturaIdentifier"/>

xs:element ref="CustomerAgreementReference"/>

</xs:choice

xs:element ref="Kid"/>

xs:element ref="DueDate"/>

xs:element ref="AmountDue"/>

xs:element ref="MinimumAmountDue" minOccurs="0" maxOccurs="1"/>

xs:element ref="CreditAccountNumber"/>

xs:element ref="BrandName"/>

xs:element ref="PaymentType"/>

xs:element ref="DetailReference"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="Reference" type="xs:NMTOKEN"/>

xs:element name="EfakturaIdentifier">

xs:simpleType

xs:restriction base="xs:string">

xs:maxLength value="9"/>

xs:minLength value="9"/>

xs:pattern value="[0-9]{9}"/>

</xs:restriction

</xs:simpleType

</xs:element

xs:element name="CustomerAgreementReference" type="xs:NMTOKEN"/>

xs:element name="Kid" type="xs:integer"/>

xs:element name="DueDate" type="xs:integer"/>

xs:element name="AmountDue" type="xs:NMTOKEN"/>

xs:element name="MinimumAmountDue" type="xs:NMTOKEN"/>

xs:element name="CreditAccountNumber" type="xs:integer"/>

xs:element name="BrandName" type="xs:string"/>

xs:element name="PaymentType" type="xs:integer"/>

xs:element name="DetailReference" type="xs:anyURI"/>

xs:complexType name="ServiceProviderId">

xs:sequence

xs:element ref="ServiceProviderId"/>

</xs:sequence

</xs:complexType

xs:element name="ServiceProviderId" type="xs:NMTOKEN"/>

</xs:schema

4Overviewovernotificationsthatmaybesentinthe incomingtransmission

Thetransactionlevel states thetypeof transactionsanassignment contains. Thefollowingtable showsanoverviewovertheelementsnecessary todefineaduepayment.

4.1 PaymentRQ

TAG / DESCRIPTION / FORMAT
PaymentRQ / Thestart ofanewpayment. New tagswill appearhereifthereare
newtypesof“documents”.
Forexample: insurancepolicies. / -
PaymentRQInfo> / Informationofwhichservices this paymentinformationisregarding. / -
ProductId / Theservicecodefor eInvoice. / •Numerical
•Always42
NumberOfTransactions / Numberof transactions ina transmission / •Numerical
PaymentAdd> / Duepaymentinformationdistributed toissuer’scustomerviatheinternet
bank. / -
Reference> / Uniquereferencefor thispayment transaction.Thereferencewill be
returnedinareceipt file.
Thefieldwill becheckedfor duplicatedwithNETS.
Forexample: 200206150000001 / •Numerical,15characters
•Format: YYYYMMDDXXXXXXX
Explanation:
•yyyy=year
•mm = month
•dd= day
•xxxxxxx=uniqueserial number,ascendingfrom
0000001
CustomerAgreement
Reference / Customer’seInvoice reference/
document reference
One of CustomerAgreementReference> or EfakturaIdentifier may be used. / •Alfanumerical
•Nospace
•Noperiod
•Max32characters
EfakturaIdentifier / Customer’s unique identifier.
One of CustomerAgreementReference> or EfakturaIdentifier may be used. / •Numerical
•9 digits
Kid> / KID or othercustomer reference validin modulus10or 11. / •Numerical
•Nospace
•Noperiod
•Max25characters
DueDate> / Invoiceduedate. / •Nospace
•Noperiod
•Format =DDMMYYYY
•Max8characters
AmountDue> / Invoiceamount due. / •Period marksthousand
•Commabeforedecimals
•Twodecimals
<MinimumAmountDue> / The minimum amount that must be paid for this invoice. This element is optional / •Period marksthousand
•Commabeforedecimals
•Twodecimals
CreditAccountNumber / Creditor’saccount number. Used
whenpayingbills.
Accountintowhich theissuerwants toreceivecustomer’spayment. / •Numerical
•Nospace
•Noperiod
•Mustbevalidin modulus
•Max11characters
BrandName / Issuer/product name.Showswhich
issuer/product thebill concerns. / •Alfanumerical
•Max40characters
PaymentType> / Describespayment type.Two types ofpayment; NettgiroandATG. / •0 (Nettgiro)
•1 (ATG)
•Max2characters
DetailReference / URL that pointstoaspecific invoice/document. / •Alfanumerical
•Max500characters Must start with:

or

4.1.1 Scenario for exchangeof duepayment (PaymentAdd)

•eBillinghotel/issuer sendsatransmissionwithPaymentRQPaymentAdd.

•NETSvalidates thetransmissionlevel first andsendsa1stlevel receipt.

•NETSvalidates theassignment information (ContentProviderRQ)andeachofthedue payments(PaymentAdd) andreturnsaneBillinghotel/issuer 2ndlevel receipt.

TheeBillinghotel/issuer must handlethe1stand2ndlevel receiptsfromNETS andcorrectany errors. Errorsmust bereportedin the1stand2ndlevel receipts.

5Specificationsforoutgoingtransmissions(receiptfor transmission)

5.1 Transmissionlevel

Thetransmissionlevel isthetoplevel in themessage. It contains informationabout sender and receiveroftheoutgoingtransmission.

TAG / DESCRIPTION / FORMAT
?xml version="1.0"
encoding="ISO-8859-
1"?> / Thecodemustbeat thetopof thefileto
ensurecorrect formatting/character setinthe
XMLfile. / -
Message> / Marksthestartandendofthemessage. / -
Response> / Headerinformationabout themessage. / -
FromInfo> / Containsinformationaboutsender. / -
ServiceProviderId> / Sender / •Numerical, 4characters
•Always=8080
ServiceProviderFileD
ate> / Datewhen messagewassent. / •Format :DDMMYYYY
•Noperiod
•Nospace
ServiceProviderFileR
eference / Datafieldthat statesthefile/transmission’s
uniquereferencefrom NETStosender. Forexample: 20020615001 / •Numerical,11characters
•Format: YYYYMMDDXXX
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXX =uniqueserial number,ascendingfrom
001
ServiceProviderFileS
tatus / Describesifthefilecontains testor productiondata.Ref. sametaginincoming
transmissionwithlocal invoicestorage.
0=Test
1= Production / •Numerical,1character
•0=Test
•1= Production
ToInfo> / Containsinformationabout recipient. / -
ServiceProviderId> / Recipient / •Alfanumerical,14 characters
•Format =NORissuer’s idwithNETS
FileReceptionReceip
t> / Header for1 level receipt. Onlyappearson
1stlevel receipts.
Containsinformationaboutvalidationon1st level.
XMLsyntax/DTD check.
Elementshavebeencorrectlyfilledinon transmissionlevelfor incoming transmissions. / -
ServiceProviderFileR
eference / Referencetothetransmissionsentfrom
issuer that thistransmissionfromNETSisa responseto.
Thesame valueasthe ServiceProviderFileReferencein the incomingtransmissions. / •Numerical,11characters
•Format: YYYYMMDDXXX
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXX =uniqueserial number,ascendingfrom
001.
StatusCode> / Codefor denial,ifany,in1stlevel receipt
(validationof XMLformat Vs.DTD). Applies totheServiceProviderFileReference> check.
Coversoxo response
Seechapter :6.1.4 / •Numerical,3characters
DuplicateStatus / Thisfieldexplains theduplicatetransmission toNETS(this transmissionnumberhasbeen usedpreviously). Thetransmissionis
thereforedenied. The”StatusCode”fieldwill alsoshowthat thisisaduplicate
transmissionwith thecorrectstatuscode. / •Numerical,1characters

5.2 Assignment level

Theassignmentlevel isa responsetotheassignments inthetransmission. It will contain informationaboutwhichassignmentstheyrespond toandwhichassignment theybelong.

TAG / DESCRIPTION / FORMAT
ContentProviderRS / Anincoming transmissioncanhavemultiple
assignments/issuers.The
ContentProviderRS>isa responsetothe
ContentProviderRQ in theincoming transmission. / -
ContentProviderInfo / Informationabout theissuer/assignment. / -
ContentProviderId> / Showswhichissuerthisassignment isfor. / •Alfanumerical , 14 characters
•Format :NORx-y
•Forexample: NOR123456789-1
ContentProviderDate / Datefor theassignmentin theincoming
transmission. / •Noperiod.
•Nospace.
•Format :DDMMYYYY
ServiceProviderFileR
eference / Referencetotheincomingtransmissionfrom
issuer that theoutgoingtransmissionfrom
NETSisa responseto.
Samevalueasthe ServiceProviderFileReference for the incomingtransmission. / •Numerical,11characters
•Format: YYYYMMDDXXX
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXX =uniqueserial number,ascendingfrom
001
ContentProviderFile
Reference / Reference totheincomingtransmissionfrom
issuer that theassignmentintheoutgoing transmissionfromNETSisaresponseto.
Samevalueasthe ContentProviderFileReference for the incomingtransmission. / •Numerical,12characters
•Format: YYYYMMDDXXXX
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXXX = uniqueserial number,ascendingfrom
0001
ContentProviderFile
Status / Statesiftheassignment isapprovedor denied.Eveniftheassignment isapproved,
partsofit maybedenied. / •Numerical,1character
•0= Assignment OK
•1= Entireassignment denied

5.3 Attachments

Examplesofhow1st level receipts,2ndlevel receipts(for deniedassignments)and2ndlevel denied transactionswill appearintheoutgoing transmission.

5.3.1 Outgoing transmission - Exampleof 1stlevelreceiptwith denied transmission (524=Errorin ServiceProviderFileDate)

Technicalmanual-DuepaymentinXMLformat

5.3.2 Outgoingtransmission-Exampleof2ndlevelreceiptfordeniedassignment

(509=InvalidContentProviderFileReference)

<?xml version="1.0"encoding="IS0-8859-1" ?>

-Message

-Response

-Fromlnfo

-ServiceProviderld

![CDATA[ 8080 ]]

/ServiceProviderld

-ServiceProviderFileDate

![CDATA[20012002]]

/ServiceProviderFileDate

-ServiceProviderFileReference

![CDATA[ 2JJ

/ServiceProviderFiIeReference

-ServiceProviderFileStatus

![CDATA[1JJ

/ServiceProviderFileStatus

/Fromlnfo

-Tolnfo

-ServiceProviderld

![CDATA[NOR999999999 ]]

/ServiceProviderld

/Tolnfo

/Response

-ContentProviderRS

-ContentProviderlnfo

-ContentProviderld

![CDATA[NOR123456789-1 JJ

/ContentProviderld

-ContentProviderDate

![CDATA[25022002JJ

/ContentProviderDate

-ServiceProviderFileReference

![CDATA[ 1JJ

/5erviceProviderFiIeReference

-ContentProviderFileReference

![CDATA[ AA1 ]]

/ContentProviderFileReference

-ContentProviderFileStatus

![CDATA[ 509 JJ

/ContentProviderFileStatus

/ContentProviderlnfo

/ContentProviderRS

/Message

5.3.3 Outgoing transmission – Exampleof2ndlevelreceiptwith1denied transaction (503= Duepaymentwith no active agreement)

5.4 XML Schema

<?xml version="1.0" encoding="UTF-8"?>

xs:schema xmlns:xs=" elementFormDefault="qualified" attributeFormDefault="unqualified">

xs:element name="Message">

xs:complexType

xs:sequence

xs:element name="Response" type="ResponseType"/>

<!-- Only second level receipt -->

xs:element name="ContentProviderRS" type="ContentProviderRSType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence

</xs:complexType

</xs:element

xs:complexType name="ResponseType">

xs:sequence

xs:element name="FromInfo">

xs:complexType

xs:sequence

xs:element name="ServiceProviderId" type="xs:string"/>

xs:element name="ServiceProviderFileDate" type="xs:string"/>

xs:element name="ServiceProviderFileReference" type="xs:string"/>

xs:element name="ServiceProviderFileStatus" type="xs:string"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="ToInfo">

xs:complexType

xs:sequence

xs:element name="ServiceProviderId" type="xs:string"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="FileReceptionReceipt" minOccurs="0">

xs:complexType

xs:sequence

xs:element name="ServiceProviderFileReference" type="xs:string"/>

xs:element name="StatusCode" type="xs:string"/>

xs:element name="DuplicateStatus" type="xs:string"/>

</xs:sequence

</xs:complexType

</xs:element

</xs:sequence

</xs:complexType

xs:complexType name="ContentProviderRSType">

xs:sequence

xs:element name="ContentProviderInfo" type="ContentProviderInfoType"/>

xs:element name="PaymentRS" type="PaymentRSType" minOccurs="0"/>

</xs:sequence

</xs:complexType

xs:complexType name="ContentProviderInfoType">

xs:sequence

xs:element name="ContentProviderId" type="xs:string"/>

xs:element name="ContentProviderDate" type="xs:string"/>

xs:element name="ServiceProviderFileReference" type="xs:string"/>

xs:element name="ContentProviderFileReference" type="xs:string"/>

xs:element name="ContentProviderFileStatus" type="xs:string"/>

</xs:sequence

</xs:complexType

xs:complexType name="PaymentRSType">

xs:sequence

xs:element name="PaymentRSInfo">

xs:complexType

xs:sequence

xs:element name="ProductId" type="xs:string"/>

xs:element name="NumberOfAcceptedTransactions" type="xs:string"/>

xs:element name="NumberOfRejectedTransactions" type="xs:string"/>

</xs:sequence

</xs:complexType

</xs:element

xs:element name="PaymentAdd" type="PaymentAddType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence

</xs:complexType

xs:complexType name="PaymentAddType">

xs:sequence

xs:element name="Reference" type="xs:string"/>

xs:element name="CustomerAgreementReference" type="xs:string"/>

xs:element name="Kid" type="xs:string"/>

xs:element name="DueDate" type="xs:string"/>

xs:element name="AmountDue" type="xs:string"/>

xs:element name="MinimumAmountDue" minOccurs="0" maxOccurs="1"/>

xs:element name="CreditAccountNumber" type="xs:string"/>

xs:element name="BrandName" type="xs:string"/>

xs:element name="PaymentType" type="xs:string"/>

xs:element name="StatusCode" type="xs:string"/>

</xs:sequence

</xs:complexType

xs:simpleType name="zeroOrOne">

xs:restriction base="xs:token">

xs:pattern value="0|1"/>

</xs:restriction

</xs:simpleType

</xs:schema

6Overviewovermessagesthatcanbesentintheoutgoing transmission

Anoutgoing transmission maycontain2receipt types (1st level and2ndlevel).Inthefuture, this format will alsobeusedtoexchangeother typesofinformation.

6.1 1stleveland 2ndlevelreceipts

Intheoutgoingtransmissionformat thereare2 receipttypes.Bothmessageswill have thesame

DTD andusesomeofthesametagsandsome tagsthatareuniquetoeach receipt type.

1stlevel receipt

•Syntaxvalidationofincomingtransmissionaccording toDTD

•NETSvalidates that thetransmissioninformationforincomingtransmissionsisfilledin according tospecificationsin thisdocument.

•Incomingtransmissionsarecheckedfor duplicatesin theServiceProviderFileReference>

field.

Iftheincoming transmissiondoesnotfulfill theserequirements, theentiretransmissionwill be deniedwithanerror messagein the1stlevel receipt.

2ndlevelreceipt

•Validationofassignment informationinincomingtransmission

•ValidationofPaymentAddinincoming transmission.

•Assignment/transactioninformationisfilledincorrectlyaccording tospecifications.

•Statusfornumber ofapproved/deniedPaymentAddin theincoming transmissionisfoundin

PaymentRSInfo.

Ifthereareanyerrorsintheassignment informationor singletransactions, thesewill bereturned in the2nd level receipt.

6.1.1 Scenario for 1stlevel2ndlevelreceipts

Thescenarioforexchangeofreceipt informationbetween theeBillinghotelandNETS:

1. TheeBillinghotel sendsatransmissiontothelocal invoicestoragewithaduepayment:

PaymentRQPaymentAdd>

NETSreturnsthetransmissionwitha1st level receiptconfirming that theformat isOK andthefile transmissionisnotaduplicate.

2. NETSvalidates theduepayment: PaymentRQPaymentAdd> in theincomingtransmission with the local invoicestorage.

NETSreturnsthe2nd level receipt withdeniedPaymentRQPaymentAdd>inPaymentRS

PaymentAdd> andastatusofapproved/denied PaymentAddin thePaymentRSInfo.

6.1.2 Explanation for1st levelreceipt

Criteriafor 1stlevel receipt:

•Therewill beoneFileReceiptionReceipt

•Therewill benoContentProviderRS

The1st level receiptwillonlycontainatransmissionlevelwithFileReceiptionReceipt>.Not an assignment or atransactionlevel.Ifdenied in1stlevel,theentiretransmissionisdenied.

Main tagswithelementsthat will beapart ofa1st level receipt:

 Noelements

 Tagsthatbothreceiptshaveincommonareinblue

 Main tagsthat deviatefrom2ndlevel receiptsareinred

 Commentsinbold

<?xml version=”1.0” encoding=”ISO-8859-1”?>

<Message>

<Response>

<FromInfo>

</FromInfo>

<ToInfo>

</ToInfo>

<FileReceiptionReceipt>Svarpåvalideringav forsendelsesnivå

</FileReceiptionReceipt>

</Response>

</Message>

6.1.3 Explanation for2nd levelreceipt

Criteria for 2ndlevelreceipt:

•FileReceiptionReceiptwill NOTappearontransmissionlevel.

•Theassignmentlevel (ContentProviderRS)will appearasmanytimesasthe

ContentProviderRQ in theincoming transmissions

•DeniedPaymentAdd: PaymentRQPaymentAdd>will be returnedin PaymentRS

PaymentAdd>

Main tagswithelementsthat will beapart ofa2ndlevel:

 Noelements

 Tagsthatbothreceiptshaveincommonareinblue

 Main tagsthat deviatefrom2ndlevel receiptsareinred

 Commentsinbold

<?xml version=”1.0” encoding=”ISO-8859-1”?>

<Message>

<Response>

<FromInfo>

</FromInfo>

<ToInfo>

</ToInfo>

</Response>

<ContentProviderRS>

<PaymentRS>

<PaymentRSInfo svarpåoppdragsnivåforoppdrag1

.

. svarpåavvistetransaksjonerUtsteder/oppdrag1

.

</PaymentRSInfo>

</PaymentRS>

</ContentProviderRS>

<ContentProviderRS>

<PaymentRSInfo svarpåoppdragsnivåforoppdrag2

.

. svarpåavvistetransaksjonerUtsteder/oppdrag2

.

</PaymentRSInfo>

</ContentProviderRS>

</Message>

Foramoredetailedexample, seechapter 6.2.

6.1.4 Reasonsfordenying1st levelreceipts

The1st or 2ndlevel receiptswill havedifferent reasonsfordenial inerror situations.

Error
codes / Description
000 / TransmissionreceivedokinNETS, transmissionstill beinghandled
001 / Transmissionisokandhasbeenhandled
524 / Invaliddateforincomingtransmission(ServiceProviderFileDate)
525 / Invalid referenceforincomingtransmission(ServiceProviderFileReference)
526 / Testdatainproduction(ServiceProviderFileStatus)
527 / Invalid recipient forincomingtransmission(ServiceProviderId)
528 / Xmlformat for incomingtransmissionisnot according toDTD
529 / Duplicateincomingtransmission(ServiceProviderFileReference)

6.1.5 Reasonsfordenialfor 2nd levelreceipts

Containsstatusforassignment andtransactionlevels

Codes that mayoccur intheContentProviderFileStatus element under the maintagof

ContentProviderInfo:

Error codes / Description
000 / Assignment ok(maycontaindeniedsingletransactions).
001 / Transmissionisokandhasbeenhandled.
101 / Error inzipfile
102 / Missingsummary.xml
103 / Error in summary.xml
104 / Error whenopening thefile
105 / Error when readingnumber
200 / Xmlisinvalidaccordingtoschema
201 / Thetransmissionisaduplicate
202 / Error innumber of files
400 / Thecustomerhasnot statedvalidorganizationnumber.
410 / Thecustomerdoesnot haveanagreement.
507 / Invalidissuer/assignmentid(ContentProviderId)
508 / Invaliddatefor theassignment (ContentProviderFileDate)
509 / Invalid referencefor theassignment in theincomingtransmission
(ContentProviderFileReference)
510 / Invalidproductid(ProductId)
511 / Error innumber oftransactionsintheassignment (NumberOfTransactions)
512 / Duplicateassignment (ContentProviderFileReference)

*Ifoneoftheseerror codesoccurs, theentireassignment will bedenied.

6.2 PaymentRS

Thetransactionlevel identifieswhich transactionstheassignment contains. Thefollowingtable showsanoverviewoftheelementsthat mayappearinareplytoanassignment inanincoming transmission.

TAG / DESCRIPTION / FORMAT
PaymentRS / Replyto thetag:PaymentRQ / -
PaymentRSInfo / -
ProductId / Contains theservicecode thatdescribes whichNETS service thisapplies to. / •Numerical,2characters
•eInvoice=42
NumberOfAcceptedT
ransactions / Numberof approvedpayment transactionsin theincomingtransmission.
Fornow; PaymentAdd / •Numerical,10characters
NumberOfRejectedT
ransactions / Numberof deniedpayment transactionsin
theassignment intheincomingtransmission. Fornow;PaymentAdd / •Numerical,10characters
PaymentAdd> / Response todeniedPaymentAdd>inthe incomingtransmission / -
CustomerAgreement
Reference / Thecustomer’seInvoicereferencewith
issuer. / •Alfanumerical,32 characters
•Nospace
•Noperiod
Reference> / Referencetothesenttransactionfromissuer that thisoutgoingtransmissionfrom NETSis
a responseto.
Thesame valueasinReferencefor transactionsintheincoming transmission. / •Numerical,15characters
•Format: YYYYMMDDXXXXXXX
Explanation:
•YYYY =year
•MM=month
•DD =day
•XXXXXXX = unique
serial number, ascending from001
BrandName / Thenameoftheproduct thepayment isfor. / •Alfanumerical , 30 characters
Kid> / KIDforpaymentsthat useKID. IfnoKIDis used,donotfill inthisfield. / •Numerical,25characters
CreditAccountNumb er / Creditcardnumber / •Numerical, characters11
DueDate> / Invoiceduedate / •Numerical,8characters
•Format :DDMMYYYY
AmountDue> / Amount / •Numerical, characters17
•Comma= øremarker
•Period= thousand marker.
<MinimumAmountDue> / MinimumAmountDue. Optional element / •Numerical, characters17
•Comma= øremarker
•Period= thousand
marker.
PaymentType> / 0= eInvoicepayment
1= ATG notice / •Numerical, characters2
DetailReference / URLfor eInvoicedetails. / •Alfanumerical, characters500
StatusCode> / Codefor deniedduepayment.Seechapter
6.2.1forpossiblecodes. / •Numerical, characters3

6.2.1 Reasonsfordenialon transaction level

Codes that mayappear in theReasonelement under themaintag; PaymentAdd: MISSING_PDF_IN_PAIR ("301"), MISSING_XML_IN_PAIR ("302"), INCORRECT_NUMBEROFFILES ("303");

Error
codes / Description
054 / Duedatehasincorrect format (DueDate)
055 / Invalidduedate(DueDate)
056 / Statedamounthas incorrectformat (AmountDue)
057 / Statedamountisnegative (AmountDue)
058 / Stated minimum amounthas incorrectformat (MinimumAmountDue)
059 / Stated minimum amountisnegative (MinimumAmountDue)
103 / Statedduedatetoofar ahead (DueDate)
145 / Creditcardnumber has incorrect format (CreditAccountNumber)
301 / pdfmissinginpdf/xml pair
302 / Xmlmissinginpdf/xml pair
303 / Erroneousnumberof filesin thetransmission
325 / KID isinvalid (Kid)
354 / Transactionreceived toolate(DueDate)
501 / InvalidcodeinPaymentType (PaymentType)
502 / Invalidcreditcardnumber(CreditAccountNumber)
503 / Duepaymentdenieddue tolackofactiveagreement
(CustomerAgreementReference, EfakturaIdentifier)
504 / Referencemissing/not filledincorrectly(Reference)
505 / Duplicate reference (Reference)
506 / DetailReference missing/not filledincorrectly (DetailReference)
550 / Warning–BrandNamenot filledin(BrandName)
(NB!Invoicewill not bedenied)