Zeichensätze

Künftig soll die Kommunikation mittels des Standards XBezahldienste konform zur verpflichtend beschlossenen Vorgabe DIN SPEC 91379 sein (String.Latin+ 1.2). Durch den Beschluss 2019/53 in der 30. Sitzung des IT-Planungsrats, wurde folgendes festgeschrieben: Alle IT-Verfahren, die dem Bund-Länder übergreifenden Datenaustausch oder dem Datenaustausch mit Bürgern und Wirtschaft dienen, müssen spätestens zum 1. November 2024 konform zur DIN SPEC 91379 sein.

DIN SPEC 91379 (String.Latin+ 1.2)

Hinweis

Nachfolgend werden die für XBezahldienste relevanten Vorgaben der DIN SPEC 91379 zusammengefasst.

Innerhalb des Standards XBezahldienste werden unterschiedliche Datentypen der DIN-Norm genutzt. Nachfolgend werden diese Datentypen kurz erläutert und mit Beispielen aus der Schnittstelle ergänzt.

Datentyp A

Der Datentyp A gibt wieder, welche Schriftzeichen in hoheitlichen Dokumenten für Namen natürlicher Personen verwendet werden. Innerhalb der Schnittstelle betrifft dies bspw. die Felder Vor- und Zuname.

Datentyp B

Der Datentyp B wurde vor allem für sonstige Namen, wie z. B. Ortsnamen und Straßennamen mit Hausnummer, entworfen. Innerhalb der Schnittstelle betrifft dies letztlich alle Felder die in Zusammenhang mit der Adresse stehen.

Datentyp C

Der Datentyp C wurde für alle normativen Schriftzeichen der DIN SPEC entworfen. Er ist somit die technische Umsetzung der Schnittstellenvereinbarung „Alle nach DIN SPEC 91379 normativen Schrfitzeichen". Texte mit griechischen oder kyrillischen Buchstaben oder mit erweiterten (nicht-normativen) Nicht-Buchstaben sind unzulässig. Innerhalb der Schnittstelle wird dieser Datentyp daher für alle Felder genutzt, deren Inhalt vom Standard eine gewisse Gestaltungsfreiheit aufweist. Dazu zählen beispielsweise die Felder 'bookingdata' oder auch 'purpose'.

Datentyp D

Dieser Datentyp kann nur von solchen IT Verfahren unterstützt werden, die auch die nicht-normativen Schriftzeichen in Anhang A der DIN SPEC 91379 unterstützen. Er wurde vor allem für Namen juristischer Personen und für Produktnamen entworfen. Innerhalb des Standards gibt es lediglich das optionale Feld 'organizationName' das bei Befüllung diesen Datentyp unterstützen sollte. Erst dieser zugeordnete Zeichensatz ermöglicht bspw. die Nutzung des kaufmännischen 'und' (&).

Mapping Datenfelder

Entsprechend der DIN SPEC 91379 werden Zeichensätze anhand der vorgestellten Datentypen festgelegt. Jedem zur Diskussion stehenden Parameter wird entsprechend des jeweilig zu erwartenden Inhalts einer der definierten Datentypen zugewiesen.

Außerhalb dieses Rasters existieren Parameter, die einen klar definierten Inhalt haben und ggf. eher technischer Natur sind. Diese werden in der API restriktiv durch ein 'Pattern' definiert und beschränken sich auf einen alphanumerischen Zeichensatz. (nachfolgend in Spalte 'Datentyp' als 'API-intern' gekennzeichent.)

Änderung zu v1.0.0	Schemas	API Parameter	Pattern?	Datentyp	Pattern	Erklärung
	PaymentInformation	transactionURL	Nein
	PaymentInformation	transactionREdirectUrl	Nein
	PaymentInformation	transactionId	Ja	API-intern	^[\w\d-]+$	techn. internes Pattern (alphanumerisch); Werte klar definiert
	PaymentInformation	transactionReference	Ja	API-intern	^[\w\d-]+$	techn. internes Pattern (alphanumerisch); Werte klar definiert
	PaymentInformation	transactionTimestamp	Nein
	PaymentInformation	paymentMethod	Nein
	PaymentInformation	paymentMethodDetail	Ja	API-intern	^[\w\d-]+$	techn. internes Pattern (alphanumerisch); Werte klar definiert
	PaymentInformation	status	Nein
	PaymentInformation	statusDetail	Ja	API-intern	^[\w\d-]+$	Datentyp C: für alle normative Schriftzeichen; Feld zur freien Verwendung in Abstimmung zwischen Bezahldienst und Fachverfahren
	paymentRequest	requestId	Ja	API-intern	^[\w\d-]+$	techn. internes Pattern (alphanumerisch); Werte klar definiert
	paymentRequest	requestTimestamp	Nein
	paymentRequest	currency	Ja	API-intern	^[\w]+$	techn. internes Pattern (alphanumerisch); Im ersten Schritt ist hier nur 'EUR' vorgesehen!
	paymentRequest	grosAmount	Nein
	paymentRequest	purpose	Ja	C		Datentyp C: für alle normativen Schriftzeichen
	paymentRequest	description	Ja	C		Datentyp C: für alle normativen Schriftzeichen
	paymentRequest	redirectUrl	Nein
	paymentItem	id	Ja	API-intern
	paymentItem	reference	Ja	API-intern	^[\w\d-]+$	techn. internes Pattern (alphanumerisch)
	paymentItem	description	Ja	C		Datentyp C: für alle normative Schriftzeichen
	PaymentItem	taxRate	Nein
	PaymentItem	quantity	Nein
	PaymentItem	totalNetAmount	Nein
	PaymentItem	totalTaxAmount	Nein
	PaymentItem	singleNetAmount	Nein
	PaymentItem	singleTaxAmount	Nein
x	PaymentItem	bookingData	Ja	C		Datentyp C: für alle normative Schriftzeichen
x	Requestor	name	Ja	A		Datentyp A: für Namen natürlicher Personen
x	Requestor	firstName	Ja	A		Datentyp A: für Namen natürlicher Personen
	Requestor	gender	Nein
	Requestor	isOrganization	Nein
x	Requestor	organizationName	Ja	D		Datentyp D: für Namen juristischer Personen
x	Address	street	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
x	Address	houseNumber	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
x	Address	addressLine	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
x	Address	postalCode	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
x	Address	city	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
x	Address	country	Ja	B		Datentyp B: für sonstige Namen, wie z.B. Straßennamen mit Hausnummer
	SystemResponse	type	Nein
	SystemResponse	status	Nein
	SystemResponse	title	Ja	API-intern	^[\w\d\s.-]+$	techn. internes Pattern (alphanumerisch)
	SystemResponse	detail	Ja	API-intern	^[\w\d\s-,.\u00C0-\u017F]+$	techn. internes Pattern (alphanumerisch)
	SystemResponse	functionalCode	Nein