<commit_before>## Notes on How Helcim Works

Following are some notes on how the Helcim gateway works. They help to put this gateway driver into context.

The Helcim service home page: https://www.helcim.com/

The Helcim site accepts either GET or POST data; they are completely interchangeable.
This gateway interface leaves the choice of which to use up to you. For a simple "donate" button or
open-ended payment form, GET would be most appropriate. If any further details need to be sent to
the form, such as customer address, names, basket detaill, the POST is more appropriate.

There are two modes of operation:

* **JavaScript mode** (`Helcim_JS`), where credit card details are taken in a form on your site, but submitted
   direct to Helcim from the form using AJAX. No customer leaves your site.
   Your site does not need PCI registration, since the CC details are not submitted direct to your site (it is
   important that the form is constructed correctly to ensure this does not inadvertently happen.
   This mode was launched in October 2014.
* **Direct mode** (`Helcim_Direct`), where credit card details are taken on your site, and no customer leaves your site.
  You will need to be PCI-registered to use this mode. Note that Helcim do not call this mode "Direct".
  This is their unnamed original API mode. It has been named "Direct" here to distininguish it from the
  later Hosted Pages mode.
* **Hosted Page mode** (`Helcim_HostedPages`), where the user is sent to one of a number of pre-defined forms on the Helcim site.
  You do not need to bve PCI-registered for this mode of operation, but there is a risk of details
  being passed between your site and Helcim being manipulated by the user.
  This is not ideal, and reconciliation therefore plays an important part in using this mode.

In the current incarnation, there is no back-channel when using the Hosted Page mode on its own. There are also
no hashes generated (using a secret known only to your site and Helcim) that can be be use to check
whether the data passed between the sites, through your browser, has been changed en-route.
With this in mind, you need to be careful not to trust the results of a successful transaction without
checking the details against the server first, i.e. don't ship the goods until you have checked the transaction
is in the Helcim account. There *is* a back-channel that your site can use to check the details of
a claimed transaction, and that is incorporated into this driver. More details on this below.

There is an API to get lists of transactions, so that can be used to check the validity of
a result posted back to your site. This will involve some overlap between the Hosted Pages and the Direct<commit_msg>Update How-Helcim-Works.md<commit_after>## Notes on How Helcim Works

Following are some notes on how the Helcim gateway works. They help to put this gateway driver into context.

The Helcim service home page: https://www.helcim.com/

The Helcim site accepts either GET or POST data; they are completely interchangeable.
This gateway interface leaves the choice of which to use up to you. For a simple "donate" button or
open-ended payment form, GET would be most appropriate. If any further details need to be sent to
the form, such as customer address, names, basket detaill, the POST is more appropriate.

There are two modes of operation:

* **JavaScript mode** (`Helcim_JS`), where credit card details are taken in a form on your site, but submitted
   direct to Helcim from the form using AJAX. No customer leaves your site.
   Your site does not need PCI registration (strictly, it reduces the PCI compliance scope, so there is no room
   for complacancy), since the CC details are not submitted direct to your site (it is
   important that the form is constructed correctly to ensure this does not inadvertently happen.
   This mode was launched in October 2014.
* **Direct mode** (`Helcim_Direct`), where credit card details are taken on your site, and no customer leaves your site.
  You will need to be PCI-registered to use this mode. Note that Helcim do not call this mode "Direct".
  This is their unnamed original API mode. It has been named "Direct" here to distininguish it from the
  later Hosted Pages mode.
* **Hosted Page mode** (`Helcim_HostedPages`), where the user is sent to one of a number of pre-defined forms on the Helcim site.
  You do not need to bve PCI-registered for this mode of operation, but there is a risk of details
  being passed between your site and Helcim being manipulated by the user.
  This is not ideal, and reconciliation therefore plays an important part in using this mode.

In the current incarnation, there is no back-channel when using the Hosted Page mode on its own. There are also
no hashes generated (using a secret known only to your site and Helcim) that can be be use to check
whether the data passed between the sites, through your browser, has been changed en-route.
With this in mind, you need to be careful not to trust the results of a successful transaction without
checking the details against the server first, i.e. don't ship the goods until you have checked the transaction
is in the Helcim account. There *is* a back-channel that your site can use to check the details of
a claimed transaction, and that is incorporated into this driver. More details on this below.

There is an API to get lists of transactions, so that can be used to check the validity of
a result posted back to your site. This will involve some overlap between the Hosted Pages and the Direct
{'fraction_non_alphanumeric': 0.03932483390195726, 'fraction_numerical': 0.0014365236128568864, 'mean_word_length': 4.138376383763838, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1844138', 'n_tokens_mistral': 1419, 'n_tokens_neox': 1353, 'n_words': 934}