{**
 * Copyright 2024-2025 Simply.IN Sp. z o.o.
 *
 * NOTICE OF LICENSE
 *
 * Licensed under the EUPL-1.2 or later.
 * You may not use this work except in compliance with the Licence.
 *
 * Copy of the Licence is available at:
 * https://joinup.ec.europa.eu/software/page/eupl
 * It is bundled with this package in the file LICENSE.txt
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the Licence is distributed on an as is basis,
 * without warranties or conditions of any kind, either express or implied.
 * Check the Licence for the specific language governing permissions
 * and limitations under the License.
 *
 * @author    Simply.IN Sp. z o.o.
 * @copyright 2024-2025 Simply.IN Sp. z o.o.
 * @license   https://joinup.ec.europa.eu/software/page/eupl
 *}
{**
 * Pay-again surface for an order whose Simply.IN payment failed. Rendered SERVER-side from the
 * shop's own order-detail hook, so the theme owns the placement — the same shape as the
 * returning-shopper offer, and the shape that ports to the sibling plugins' hook seams.
 *
 * Three mutually exclusive states, and never more than one of them: the paywall, the "a payment is
 * still being confirmed" notice that exists precisely to stop a shopper from paying again while
 * one is in flight, and the escalation once the attempts are used up. Which one is chosen is
 * decided server-side and is not re-derivable from this markup, so nothing a client can change
 * turns a notice into a payable form.
 *
 * The colour variables are set on the container rather than inherited from the document, because
 * the front-end bundle that normally sets them shop-wide does not load on an order page. Values
 * are validated as hex colours before they get here.
 *
 * type="submit" inside our own form is load-bearing: the card and BLIK flows finish their
 * client-side step and then click this very button, which is what submits the form.
 *}
{* data-order-id/data-retry-token: read by core.js to re-ask the server for this same decision once
   the live payment-status poll on the order-confirmation page learns of a definitive failure - this
   render can already be stale by then. Not a new trust boundary: the same HMAC token that already
   authorizes resubmitting a payment for this order.

   $simplyin_retry_embedded: order-confirmation embeds this markup inside the status widget's own
   card instead of standing it up as a second one - no logo, no border/background of its
   own, both supplied by the card already wrapping it. Order-detail renders this standalone (default,
   false) and keeps its own card chrome, unchanged. *}
<div class="simplyin-retry{if $simplyin_retry_embedded} simplyin-retry--embedded{/if}" data-order-id="{$simplyin_retry_id_order|escape:'html':'UTF-8'}" data-retry-token="{$simplyin_retry_token|escape:'html':'UTF-8'}" style="--simplyin-accent-color: {$accent_color|escape:'html':'UTF-8'}; --simplyin-primary: {$accent_color|escape:'html':'UTF-8'}; --simplyin-font-color: {$font_color|escape:'html':'UTF-8'};">
    {* Mirrors the dual Simply.IN + operator artwork the checkout paywall's own option icon uses
       ({@see \SimplyIn\Payment\PaymentLogoResolver}), rather than the bare Simply.IN wordmark: a
       shopper choosing among these methods should see who is processing the payment here the same
       way they did during checkout. Falls back to the wordmark file for the decisions that never
       resolve a logo (nothing was fetched to resolve one from). *}
    {if !$simplyin_retry_embedded}
        {* Decorative: the card's own title/subtitle text already states what this surface is,
           so an empty alt lets assistive tech skip past the logo rather than reading a fixed
           "simply.in" that would be wrong for the operator-branded artwork above. *}
        <img class="simplyin-retry-logo" src="{$module_path|escape:'html':'UTF-8'}views/img/{$simplyin_retry_logo|default:'logo_medium.svg'|escape:'html':'UTF-8'}" alt=""/>
    {/if}

    {* Gated on the paywall having something payable in it, not only on the verdict: a card whose
       button cannot lead anywhere is worse than the escalation copy below, and the verdict itself
       stays exactly what the policy returned rather than being rewritten to steer this branch. *}
    {if $simplyin_retry_decision == 'retry_allowed' && $simplyin_retry_paywalls}
        <div class="simplyin-retry-copy">
            <span class="simplyin-retry-title">{l s='Your payment did not go through' mod='simplyin'}</span>
            {* The one fact this surface is sure of, restated plainly rather than left unsaid: never a
               specific decline code and never anything fraud-related, since neither is ours to state
               to a shopper.

               The badge is the visible marker that the icon dropped from this surface when it was
               embedded into the order-confirmation status card (nothing of its own to pair with, so
               it was not repeated as an orphaned glyph) - paired with the one sentence that states
               the failure, rather than standing alone. *}
            <span class="simplyin-retry-subtitle simplyin-retry-subtitle-with-badge"><span class="simplyin-retry-badge">{l s='Failed' mod='simplyin'}</span> <span class="simplyin-retry-reason">{l s='We could not process your payment.' mod='simplyin'}</span></span>
            {* Says plainly that nothing about the order changes, because that is the shopper's real
               question here — they are looking at an order they already placed. *}
            <span class="simplyin-retry-subtitle">{l s='You can pay for this order again below. The order number, delivery address and total stay exactly as they are.' mod='simplyin'}</span>
        </div>

        {if $simplyin_retry_failed}
            {* Shown when the previous submission was refused before any payment was started, so the
               shopper is not left wondering whether something happened. No reason is given: the
               refusals that reach here are ours (no method chosen, state moved on), never the
               payment provider's, and provider detail is never shown to a shopper regardless. *}
            <div class="simplyin-retry-error">{l s='We could not start that payment. Please choose a payment method and try again.' mod='simplyin'}</div>
        {/if}

        <form class="simplyin-retry-form" method="post" action="{$simplyin_retry_action|escape:'html':'UTF-8'}">
            <input type="hidden" name="id_order" value="{$simplyin_retry_id_order|escape:'html':'UTF-8'}">
            <input type="hidden" name="retry_token" value="{$simplyin_retry_token|escape:'html':'UTF-8'}">
            {foreach $simplyin_retry_paywalls as $simplyin_retry_paywall}
                {$simplyin_retry_paywall nofilter}
            {/foreach}
            <button type="submit" class="simplyin-retry-button">{l s='Try again' mod='simplyin'}</button>
        </form>
    {elseif $simplyin_retry_unavailable}
        <div class="simplyin-retry-copy">
            <span class="simplyin-retry-title">{l s='Paying for this order is unavailable right now' mod='simplyin'}</span>
            {* The order IS payable - we just could not load the payment methods this time. Says so,
               rather than borrowing the definitive copy below, which would tell a shopper to contact
               the shop over what is very likely a momentary problem. *}
            <span class="simplyin-retry-subtitle">{l s='We could not load the payment methods. Please refresh the page in a moment to pay for this order.' mod='simplyin'}</span>
        </div>
    {elseif $simplyin_retry_decision == 'payment_in_progress'}
        <div class="simplyin-retry-copy">
            <span class="simplyin-retry-title">{l s='Your payment is being confirmed' mod='simplyin'}</span>
            {* No retry control at all, and the copy says why: a shopper told only "please wait" goes
               looking for another way to pay, which is the outcome this whole state exists to
               prevent. No time estimate is given, because how long this legitimately takes depends
               on the payment method and we would only be guessing. *}
            <span class="simplyin-retry-subtitle">{l s='We are waiting for confirmation of a payment for this order. Please do not pay again — if the payment does not succeed, you will be able to pay here.' mod='simplyin'}</span>
        </div>
    {else}
        <div class="simplyin-retry-copy">
            <span class="simplyin-retry-title">{l s='We could not take a payment for this order' mod='simplyin'}</span>
            {* Reached after the attempt ceiling, and also when there is genuinely no method to offer.
               Both mean the same thing to the shopper: not here, but the order still exists and the
               shop can help. Deliberately never states a reason for the decline: the shopper is not
               told why a payment was refused, and any wording touching fraud is out of the question. *}
            <span class="simplyin-retry-subtitle">{l s='Please contact us to pay for this order another way. Your order has been kept.' mod='simplyin'}</span>
        </div>
    {/if}
</div>
