Creation of conditions based on Order Status and Payment Status when sending emails

I am trying to vary the text I send to a customer based on the order status and the payment status. For example, when sending the "OrderPlaced.CustomerNotification" I want in the code to differentiate if the order is "Pending" or "Processing" ... but I do not know which field holds the order status in the "Order" structure.

Here is an example that works:

%if (%Order.PaymentMethod% == ”Bank Deposit”) <b> BANK DEPOSIT </b> endif%

Here is an example that does not work:

%if (%Order.Status% == ”Pending”) <b> ORDER PENDING</b> endif%

Where can I find the list of fields that can be used with the "Order" record/data structure?

Many thanks!

When editing a message template up the top is a link
Allowed message tokens: Show - Click on Show and it will display the Message Tokens available
but Order.Status is not a valid message token

But if you know the standard Order Workflow then for the respective message templates you should be able to hard code the values in each different message template

Message Template OrderPlaced.XXX will be OrderStatus == Pending and PaymentStatus == Pending or Paid
Message Template OrderPaid.XXX will be OrderStatus  == Processing  and PaymentStatus == Paid
Message Template OrderCompleted.XXX will be OrderStatus == Completed and PaymentStatus == Paid

Yinda, many thanks for showing me how to reveal the message tokens used in a message template!

From what you say (and what I saw in the allowed tokes list) I understand that since the Order Status does not appear in the list I can not use the order status (and the payment status) in an "if" condition within that message template. For me this creates the following issue: When the customer payment (via credit card) fails the customer receives an email that the order was placed (which is not true). I wanted to use the order staus and the payment status to deduce what happened (e.g. if (OrderStatus == pending and PaymentStatus == Not Paid) Then "something went wrong").

Not sure how others have dealt with the fact that NOP does not seem to have an "error" state within the order state machine (from what I have seen the order states are Pending, Processing, Complete, Canceled); which admitedly are "enough" if one can combine it with payment status logic.

Any ideas how I can get out of this loophole? Your last reply seems to show a small light of hope but I am not sure ...

An If condition is not going to help here as it is going to send which ever email regardless unless you start customising the code. If you don’t want the customer to get an email when they Place an order and only when they Make Payment for an order i.e. the order is Paid - then just use the correct Message Template i.e. enable Order Paid and disable the Order Placed.

Which payment method are you using - I guess you are a Redirection Method i.e. payment is made after the order is created ?
One thing about redirection payment methods - you can never really guarantee you will get the message back to say an Order is Paid. There is always a chance that the customer will place an order and the order payment message is not received. i.e. there is a network glitch, the Api does not work, the customer’s phone runs out of power. And so the order does not get paid and the customer never receives any email i.e. the order sits there as pending and unless you check the Merchant Desktop then the order does not get set to Paid.
Of course 99% of the time it always works but this is the reason for the design of the system and the way it works - so it is not a glitch as such.

There is also various mechanisms you can add to a payment method to deal with error situations. Retrying the payment, automatically cancelling an order and return the customer to a full cart, sending reminder emails  for payment, and others etc

Hi Yinda, first of all apologies I did not reply sooner; I was on vacation and only just got back.

Your suggestion that I do not send the mesage is prehaps the real solution; I will configure which messages go depending on the payment methods we use.

I understand it is how it is designed!

Again, many thanks for your prompt replies and your insights!

Nikos