Skip to main content
Every shop needs a page on which payment methods and shipping costs are fully explained once. Legally it is mandatory, and in practice buyers look there before they order. This page should show all details, regardless of what is currently in the basket and where the delivery is going. This is exactly what the TAC- tags do. The name stands for “terms and conditions”. They read the payment and shipping methods directly from the shop configuration and output them without a single check against the current process. Two families share the work: TAC-P- for payment methods and TAC-D- for shipping methods. Guide: Global display of payment and shipping methods
All tags on this page are permitted on all templates. A separate template that is included via a content page is common. Every tag except the two loop tags TAC-P-Data and TAC-D-Data requires the respective loop around it; outside it, it is an invalid tag.
These tags describe the configuration, not the selection in the current order process. For the payment methods a buyer can actually choose right now, there are the PAY- tags, and for the shipping methods the DELIV- tags. A payment method that appears here may still be excluded in the order process, for example because of the delivery country or the value of the goods.
  • Reference: PAY- (payment methods)
  • Reference: DELIV- (shipping methods)

What is displayed at all

Neither loop iterates over all configured entries, only over those intended for list display. This is a separate switch for each payment or shipping method in the shop configuration.
If a payment method is missing on the finished page, this is almost always due to this switch and not the template. The previous documentation does not mention it and gives the impression that the loops iterate over all configured entries.
The order of the payment methods follows the position assigned in the shop configuration, not the order of the entries in the file. The shipping methods, on the other hand, appear in the order of their entries.
Assign each position only once. If two payment methods have the same position, the loop shows only the first of them; the second silently drops out of the list. The same applies to a payment method without a position. The previous documentation does not state this.

The payment methods

The loop

TAC-P-Data can do all three: output the number as a single tag, check as a bracketing whether there are any entries at all, and loop over them.

The details per payment method

TAC-P-Img returns a complete path, because the shop system prepends the directory of the navigation graphics. Bracket the output anyway, because not every payment method has a graphic stored, and an img element with an empty src reloads the page itself.
TAC-P-Code is the internal index of the payment method, not its position in the list. The numbers therefore do not run in display order. For sequential numbering, count in the template yourself.

The cost scale

The costs of a payment method depend on the value of the goods and are stored as a scale. TAC-P-CostData loops over it.
Depending on the configuration, TAC-P-CostData_value returns an amount or a percentage, without a unit. Only TAC-P-CostData_percentageValue tells you which of the two it is. Therefore, always write the currency symbol and the percent sign via the two bracketings and never hard-code them in the template.
TAC-P-CostData_amount() takes up to two parameters, namely the number of decimal places and the decimal separator. Without parameters, the tag outputs the value unformatted. For amounts, (2) is the usual setting.
If a payment method has no costs stored, TAC-P-CostData does not apply as a bracketing. The negative bracketing is therefore suitable for a notice that this payment method is free of charge.

The country lists

For each payment method, you can define which countries may be delivered to and for which countries the invoice may be issued. Both work the same way and consist of two steps: first, a bracketing tells you what kind of list it is, and within it a loop iterates over the countries.
For the delivery countries, there are the same five tags with DeliveryCountries or DeliveryCountryData in the name.
The two complete bracketings exist in the shop system but are not described in the previous documentation. The supplied sample templates use them nevertheless, and rightly so, because they answer the question a buyer asks.
The difference from the documented _allow and _deny is significant. TAC-P-BillCountries_allow only applies if the configuration is written as an allowlist, and then shows exactly this list. If it is written as a denylist, it does not apply at all. The complete version, by contrast, builds the inverse list from the country file in this case and thus answers the actual question. For a customer-facing page, use the complete version; the plain _allow and _deny are better suited for checking the configuration.
Which countries are in the inverse list comes from the shop’s country files. For billing countries, this is the general country list; for delivery countries, the list of countries that can be delivered to. The two can differ.
The order matters. The bracketing builds the country list, and only then can the associated loop iterate over it. Therefore, always place the loop within the bracketing. Conversely: within a running country loop, the bracketings return nothing; they cannot be nested there.
As a single tag, the two CountryData tags output the entire list as a comma-separated sequence of ISO codes. This is not described in the previous documentation and is suitable for passing to your own scripts.
If no country restriction at all is stored for a payment method, all bracketings remain silent. The outer bracketing TAC-P-BillCountryData is therefore suitable as a frame around the entire country block, as in the example above.

The shipping methods

The shipping methods work just like the payment methods. Three things are added: a second cost scale by weight, an additional country field and three checks for special order types.

The loop and the details

TAC-D-Img outputs the stored value unchanged, unlike TAC-P-Img, to which the shop system prepends the directory of the navigation graphics. Therefore, store the complete path for a shipping method, otherwise the browser will not find the graphic. The previous documentation describes both tags identically as “graphic for the shipping method (path)”.
TAC-D-Country exists in the shop system but is not described in the previous documentation. It outputs the country field of the shipping method, that is, an additional value from the configuration, and should not be confused with the country list below.

The two cost scales

Shipping costs can depend on the value of the goods, on the weight, or on both. There are two separate loops for this.
The weight scale has no percentage. TAC-D-WeightCostData_value is always an amount and already comes in the shop’s number format. There is no counterpart to _percentageValue here.
Both _amount tags take the number of decimal places and the decimal separator as parameters. For weights, (1) is usually appropriate; for amounts, (2).
The “free shipping” notice line in the example needs both negative bracketings nested inside each other, because a shipping method is only free of charge if neither a value-of-goods scale nor a weight scale is stored.

The delivery countries

The delivery countries of a shipping method work exactly like the country lists of the payment methods, including the difference between _allow and completeAllow.
Here, too, TAC-D-DeliveryCountries_completeAllow and _completeDeny exist in the shop system and are not described in the previous documentation. Everything about the order and the inverse list applies unchanged; see above under payment methods.

Special order types

Three bracketings tell you for which type of order a shipping method is intended. All three strictly require a parameter.
All three tags are invalid without a parameter, and an unknown parameter also makes them invalid. They do not exist as single tags. The previous documentation mentions this condition only for TAC-D-SubscriptionOrderState(), but it applies equally to all three.
The three tags check for equality with exactly one setting. If you want to output something for all cases except one, use the negative bracketing, not a different parameter.
  • Reference: PRIME- (PrimeShopping)
  • Reference: SUBS- (taking out a subscription)

Tags at a glance

Payment methods

Shipping methods

The “Applies in” column names the loop within which the tag must be placed. Outside it, it is an invalid tag. The two CountryData tags each belong in the loop of their own level, not in the data loop above it.
  • Guide: Global display of payment and shipping methods
  • Guide: Creating payment methods
  • Guide: Creating shipping methods
  • Reference: PAY- (payment methods)
  • Reference: DELIV- (shipping methods)