wp-pay-gateways/ideal-advanced-v3

iDEAL Advanced v3 driver for the WordPress payment processing library.

v4.3.7 2023-10-13 12:12 UTC

Requires

• php: >=7.4
• ext-dom: *
• ext-openssl: *
• pronamic/wp-http: ^1.1
• wp-pay-gateways/ideal: ^4.1
• wp-pay/core: ^4.6

Requires (Dev)

• automattic/wordbless: ^0.4.2
• bamarni/composer-bin-plugin: ^1.8
• overtrue/phplint: ^9.0
• php-coveralls/php-coveralls: ^2.6
• phpmd/phpmd: ^2.14
• pronamic/pronamic-cli: ^1.1
• pronamic/wp-coding-standards: ^2.0
• roots/wordpress: ^6.0
• wp-phpunit/wp-phpunit: ^6.1
• yoast/phpunit-polyfills: ^1.1

GPL-3.0-or-later

• Pronamic
• Remco Tolsma

• wordpress
• pay
• gateway
• ideal
• v3
• wp
• advanced
• pronamic

README

iDEAL Advanced v3 driver for the WordPress payment processing library.

Providers

• ING
• Rabobank

Documentation

Title	Language	Version	Date
iDEAL Merchant Integration Guide	EN	3.3.1	2015-02
iDEAL Merchant Integratie Gids	NL	3.3.1	2015-02
iDEAL Merchant Integration Guide	EN	3.3.1	2012-11
Rabobank - Handleiding iDEAL Professional	NL	3.0	2019-02
iDEAL Merchant Integratie Gids (NL)	NL	3.6	2020-10-09
iDEAL Merchant Integration Guide (EN)	NL	3.6	2020-10-09

Signing iDEAL messages

All messages that are sent by the Merchant to the Acquirer (DirectoryRequest, TransactionRequest and StatusRequest) have to be signed by the Merchant. Messages are signed in accordance with the "XML Signature Syntax and Processing (2^nd Edition) W3C Recommendation” of 10 June 2008⁴, with the following settings and restrictions applied:

1. The entire XML message⁵ must be signed.

2. For the purpose of generating the digest of the main message, the inclusive canonicalization algorithm must be used⁶. This method of canonicalization of the main message is not (always) explicitly indicated in the iDEAL XML messages. For this reason this transform has not been included in the example messages in this document. Merchants are not required to explicitly indicate this transform in their messages.

3. For the purpose of generating the signature value, the exclusive⁷ canonicalization algorithm must be used.

4. The syntax for an enveloped⁸ signature must be used. The signature itself must be removed from the XML message using the default transformation prescribed for this purpose.

5. For hashing purposes the SHA-256⁹ algorithm must be used.

6. For signature purposes the RSAWithSHA256¹⁰ algorithm must be used. RSA keys must be 2,048 bits long.

7. The public key must be referenced using a fingerprint of an X.509 certificate. The fingerprint must be calculated according to the following formula HEX(SHA-1(DER certificate)) ¹¹.

   Note: the key reference is backwards compatible with all previous versions of iDEAL.

   Note: According to Base64 specifications line breaks are allowed to be inserted after each 76 characters using a CR/LF¹².

In general Merchants don’t need to have extensive knowledge of RSA since most programming languages have libraries available that implement XML Digital Signature processing. It is strongly recommended to use these standard libraries. Standard functionality for creation and verification of RSAWithSHA256 digital signatures is available in commonly used software platforms, from the following versions and higher: PHP version 5.3.0, Microsoft .NET version 3.5 sp1 en Java version 1.6 u18.

This functionality may also be available in earlier versions of these platforms and in other platforms (e.g. Python, Ruby).

For information about creating the public and private key pair please refer to paragraph 8.4.

⁴ http://www.w3.org/TR/xmldsig-core/
⁵ XML Signature reference to the signed info URI is left blank, see example messages in Appendix B
⁶ http://www.w3.org/TR/2001/REC-xml-c14n-20010315
⁷ http://www.w3.org/2001/10/xml-exc-c14n
⁸ http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
⁹ http://www.w3.org/2001/04/xmlenc#sha256
¹⁰ http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/#sec-SHA256
¹¹ See example messages in Appendix B
¹² http://tools.ietf.org/html/rfc2045#section-6.8