PAYMORROW- (Paymorrow) - WEBSALE Dokumentation

With Paymorrow, it is not the shop that decides on the payment method, but the service provider. The shop sends a request for the current basket and the address data, and Paymorrow responds with an approval or a rejection. If the approval is positive, the response also provides the bank details to which the buyer should transfer the money. This results in two groups of tags. PAYMORROWPI- outputs this payment information on the order confirmation, and this is the part that every template needs. PAYMORROW- shows the complete raw responses and is intended for test mode only. Guide: Paymorrow

Two payment methods, two requests

In the shop system, Paymorrow serves two payment methods: purchase on invoice and direct debit. Both run via the same integration, but have their own configuration and their own approval. A rejection for purchase on invoice therefore does not also block direct debit. Each payment method goes through two requests to Paymorrow.

Step	Task
`getPaymentToken`	registers the basket and address data and retrieves a payment token
`authorizeByRef`	authorizes the purchase with this token

Two payment methods times two requests times two formats result in the eight PAYMORROW- tags further below.

If Paymorrow rejects definitively, the shop system remembers this for the session and hides the payment method in the selection or shows it grayed out. In the template, you can see this via PAY-Data_disabled. You do not need a separate PAYMORROW- tag for this.

Reference: PAY- (Displaying and selecting payment methods)

Outputting the payment information

After a successful authorization, Paymorrow provides the data to which the buyer should transfer the money. The tags of the PAYMORROWPI- family retrieve this data individually. The part after the hyphen is the field name as Paymorrow writes it in the response.

Tag	Returns
`PAYMORROWPI-recipientName`	the name of the beneficiary
`PAYMORROWPI-recipientBankName`	the bank of the payee
`PAYMORROWPI-recipientIBAN`	the IBAN of the payee
`PAYMORROWPI-recipientBIC`	the BIC of the payee
`PAYMORROWPI-recipientNBAN`	the account number of the payee
`PAYMORROWPI-recipientNBC`	the bank code of the payee
`PAYMORROWPI-referenceTextLine1`	the payment reference, first line
`PAYMORROWPI-referenceTextLine2`	the payment reference, second line

{PAYMORROWPI-recipientName}
   <h2>Bitte überweisen Sie auf folgendes Konto</h2>

   <dl>
      <dt>Kontoinhaber</dt>
      <dd>~PAYMORROWPI-recipientName~</dd>

      <dt>Kreditinstitut</dt>
      <dd>~PAYMORROWPI-recipientBankName~</dd>

      <dt>IBAN</dt>
      <dd>~PAYMORROWPI-recipientIBAN~</dd>

      <dt>BIC</dt>
      <dd>~PAYMORROWPI-recipientBIC~</dd>

      <dt>Verwendungszweck</dt>
      <dd>
         ~PAYMORROWPI-referenceTextLine1~
         {PAYMORROWPI-referenceTextLine2}<br>~PAYMORROWPI-referenceTextLine2~{/PAYMORROWPI-referenceTextLine2}
      </dd>
   </dl>
{/PAYMORROWPI-recipientName}

The tags only work once the order has been completed. Before that, they are treated as an invalid tag, even on one of the permitted templates. That is why they are placed exclusively on the order confirmation, in its PDF, and in the confirmation email.

Wrap the entire block with a field that is always filled, for example PAYMORROWPI-recipientName. For any other payment method, the data is not available, the range tag does not apply, and the heading disappears together with the block.

The two lines of the payment reference are not both guaranteed to be filled. Wrap the second line in a range tag, otherwise there will be an empty line break there.

Further fields from the response

The shop system stores all fields of the payment information as a list and, when resolving a tag, simply searches for the name after the hyphen. If Paymorrow returns a field that is not listed above, you can access it with the same pattern.

{PAYMORROWPI-<Feldname aus der Antwort>}
   ~PAYMORROWPI-<Feldname aus der Antwort>~
{/PAYMORROWPI-<Feldname aus der Antwort>}

A field name that the response does not contain is not an error. The single tag then outputs nothing and the range tag does not apply. So you can access a field that is only supplied under certain circumstances without breaking the template.

The values are output HTML-encoded. You can place them on the page and in the email without further processing.

The raw responses in test mode

For troubleshooting, the shop system outputs the complete responses from Paymorrow. They are available per payment method, per request, and in two formats.

Tag	Payment method	Request	Format
`PAYMORROW-XMLResponseGetPaymentToken`	Invoice	`getPaymentToken`	XML
`PAYMORROW-JSONResponseGetPaymentToken`	Invoice	`getPaymentToken`	JSON
`PAYMORROW-XMLResponseAuthorizeByRef`	Invoice	`authorizeByRef`	XML
`PAYMORROW-JSONResponseAuthorizeByRef`	Invoice	`authorizeByRef`	JSON
`PAYMORROW-DebitXMLResponseGetPaymentToken`	Direct debit	`getPaymentToken`	XML
`PAYMORROW-DebitJSONResponseGetPaymentToken`	Direct debit	`getPaymentToken`	JSON
`PAYMORROW-DebitXMLResponseAuthorizeByRef`	Direct debit	`authorizeByRef`	XML
`PAYMORROW-DebitJSONResponseAuthorizeByRef`	Direct debit	`authorizeByRef`	JSON

{PAYMORROW-XMLResponseAuthorizeByRef}
   <pre>~PAYMORROW-XMLResponseAuthorizeByRef~</pre>
{/PAYMORROW-XMLResponseAuthorizeByRef}

Outside of test mode, all eight tags output nothing, and the range tag does not apply. You can therefore leave them in the template permanently without a buyer ever seeing any of it. Nevertheless, do not rely on this alone: the responses contain address and order data and do not belong on any page that is accessible in live operation.

Paymorrow responds exclusively in XML. The JSON variant is a conversion by the shop system, not a second format from the service provider. For troubleshooting with Paymorrow, the XML version is therefore the authoritative one.

The output is HTML-encoded. The angle brackets of the XML therefore appear as text and do not break the page. A pre element around the tag makes the response readable.

Each response is only available if the corresponding request took place in the same page request. So place the tags on the page on which the process is triggered, not on any later page.

The tags at a glance

Tag	Single tag	Range tag	Negative range tag	Loop tag
`PAYMORROWPI-<Feldname>`	yes	yes	yes	–
`PAYMORROW-XMLResponseGetPaymentToken`	yes	yes	yes	–
`PAYMORROW-JSONResponseGetPaymentToken`	yes	yes	yes	–
`PAYMORROW-XMLResponseAuthorizeByRef`	yes	yes	yes	–
`PAYMORROW-JSONResponseAuthorizeByRef`	yes	yes	yes	–
`PAYMORROW-DebitXMLResponseGetPaymentToken`	yes	yes	yes	–
`PAYMORROW-DebitJSONResponseGetPaymentToken`	yes	yes	yes	–
`PAYMORROW-DebitXMLResponseAuthorizeByRef`	yes	yes	yes	–
`PAYMORROW-DebitJSONResponseAuthorizeByRef`	yes	yes	yes	–

The PAYMORROWPI- tags apply on the order confirmation ws_confirm.htm, in its PDF version pdf_confirm.htm, and in the order confirmation email mail_customer_order.htm, in each case only after the order has been completed. The PAYMORROW- tags are permitted on all templates.

Guide: Paymorrow
Guide: Designing the order confirmation
Reference: PAY- (Displaying and selecting payment methods)

​Two payment methods, two requests

​Outputting the payment information

​Further fields from the response

​The raw responses in test mode

​The tags at a glance

​Related topics

Two payment methods, two requests

Outputting the payment information

Further fields from the response

The raw responses in test mode

The tags at a glance

Related topics