Skip to main content

Payment Redirect Additions

Some payment methods of Wallet Balance and Direct Charge such as giropay bank let the end user handle the transaction in the own UI of the payment method provider then do a redirect back to the ATS UI when transaction is completed.


We have added support to handle this callback so the end user can see the result of their transaction.


User gets redirected back to the ATS site with the ATS site query parameters preserved, with a couple of additional query parameters that HAPI Elements adds before the redirect, and some that are added by Stripe during the redirect. Here is how the URL looks after redirect (new lines are added for readability):

https://ats-site.com
    ?ownParameter=ownValue
    &__hePaymentResult=true
    &payment_intent=pi_3PLhQnDpE4Kuihgq3gzr8EP1
    &payment_intent_client_secret=pi_3PLhQnDpE4Kuihgq3gzr8EP1_secret_ed4MHqVA8b7t0DRln31mogmo7
    &redirect_status=succeeded

When HAPI Elements sees the __hePaymentResult query parameter, it opens up a modal with details to the payment via the value of payment_intent_client_secret query parameter. HAPI Elements removes these query parameters added to restore it back to the way URL was before the redirect.


The only way to get redirected is to pay with payment method providers that require a redirect. The end user can only pay on these widgets:

There are these scenarios that can happen:

  1. User adds wallet balance via the top up widgets NOT during order
    • This means you have the wallet widget available in your site globally. Once the user gets back to your site, they will see the modal with the payment status
  2. User selects "Pay with Wallet" during order via the form inside payment-method step of the Order journey, and they want to top-up balance to the wallet
    • At this stage, campaign is not created as the end user has not confirmed payment for the campaign yet (they did confirm payment for the wallet balance top-up though). This means user needs to resume campaign ordering process after the redirect. The end user might change their mind after adding the wallet balance, so the whole state is restored for end user to pay with the newly added balance or an alternative method
  3. User selects "Pay Now" during order via the form inside payment-method step of the Order journey
    • At this stage, because the end user confirmed for the payment of the campaign, campaign is created as a draft. There are some payment methods that take some time to be confirmed so campaign status is draft until payment is successful. Until then, in the modal that opens, user will see the status of the payment as well as the UI for the campaign. If payment was unsuccessful, user can still pay in the campaign UI.
info

For the item 2 above, to work, when user lands back on the ATS site, the order journey widget should be visible in the page (not hidden behind tabs, modals etc.) so that the end user can resume their order process. The entire HAPI Elements state is restored so the prefills etc. you ran are preserved (such as hiding some order journey steps, hiding payment methods etc.)

In other words, if you have structure like this, then you might need to make code adjustments:

  1. User lands on your page /order
  2. User clicks a button, a tab, a modal or a section appears however the page URL does not change to reflect the state such as /order?openModal=hapiElementsOrder

This is similar in behavior to the contract add widget limitations as described here, so the order widget should be on a dedicated page.