There are a number of payment methods in Infigo but their functionality isn't like for like. This table explains what each plugin does (and doesn't do).

Infigo currently supports many different payment types from many different payment providers, and you can control which ones do and do not appear in the checkout process with ease.

Please note that this article will notbe covering how to configure these payment methods, rather it will be covering how to control whether or not the user is able to see and select them during the checkout process.

In order to control which ones the user is able to see, you will need to sign in as a storefront administrator (or someone with equal access) and navigate to Configuration > Payment Methods. 

This will take you to a page displaying all of the available payment methods on your storefront.

From here, it is a simple process to enable/disable payment methods in the checkout. In the below example, Purchase Order will be disabled and PayPal will be enabled. 

1. To disable a payment method, press Edit, then un-tick the payment method. 

Then, press Update. 

2. Navigating back to the frontend, Purchase Order will no longer be able to be selected at checkout. 

Everything about the Stripe payment plugin is now in one place: the Stripe Payments hub. It covers creating your Stripe account and API keys, connecting Stripe to your storefront, the webhook, capture modes, testing with Stripe test cards, going live, what your shoppers see, capturing, voiding and refunding orders, metadata and reconciliation, statement descriptors and receipts, and a troubleshooting section.

One of our more populate payment method plugins is PayPal Standard. This article will talk you through the steps of getting up and running and start taking payments on your Infigo storefront using PayPal.

Register for a Business Account

The first thing you need to do is register for a PayPal Business Merchant account. You can do this here. Or you can upgrade an existing non-business PayPal account by navigating to your Account Settings and clicking 'Convert to a business account'.

Setting up your PayPal Account

Now  you have a business account there are a few settings you need to configure within it to allow your Infigo storefront to communicate with it and to redirect users back from Paypal once the payment has been taken.

Firstly, navigate to 'Account settings' which can be found under your Account name in the top right hand corner.

Then down the left hand side click on 'Website payments'.

Then from the list of available settings within Website Payments click on the 'Update' button next to Website Preferences.

Within Website Preferences ensure you set the following:

• Auto-return
  • Set this to On.
  • And in the Return URL enter in the following URL: https://{yourdomain}/Plugins/PaymentPayPalStandard/PDTHandler
  • Then click Save

• Payment data transfer
  • Set this to On
  • Retrieve the Identity token from this section and save it for a future step

Now navigate back to your Account Settings, and from here select from the left hand side 'Notifications'.

Then from the list of available Notifications click 'Update' next to the 'Instand payment notifications' option.

Click 'Edit Settings' and ensure that Recieve IPN messaged is enabled and in the paste in the following URL into the Notification URL: https://{yourdomain}/Plugins/PaymentPayPalStandard/IPNHandler

Click Save.

Configuring your PayPal plugin in Infigo

Now you have configured your PayPal account you need to setup the plugin in your Infigo storefront.

Navigate to 'Payment Methods' in admin either by using the admin search or by going to Configuration > Payment Methods. From the list select 'PayPal Standard' and click Configure.

Populate the following information:

• Use Sandbox - enable this if you want to test your PayPal connection without taking actual payments
• Business Email - enter in the email address of your PayPal account here
• PDT Identity Token - Paste in the Identity token that you had saved from the previous step in here
• PDT Validate order total - enable this if you want to validate the totals in PayPal and Infigo match when payments are made
• Pass product names and order totals to PayPal - If you would like this information to be passed and visible to the customer when making the payment in their PayPal account then enable this setting
• Override the URL of IPN handler - Paste in the following URL into this field (this is different to what you entered into your PayPal account for the auto return setting) - https://{yourdomain}/Plugins/PaymentPayPalStandard/IPNHandler

Click Save and test you configuration by placing an order for some items that have a cost.

If you still encounter issues then please raise a ticket with our Support Team.

Some PayPal customers using PayPal REST may receive warning emails like:

“Please check your server that handles PayPal Instant Payment Notifications (IPN). IPNs sent to the following URL(s) failed: https://<domain>/Plugins/PaymentPayPalStandard/IPNHandler … IPNs may be disabled for your account.”

This can be confusing because PayPal REST integrations typically use Webhooks, not IPN.

This guide explains what’s going on and what to change.

IPN vs Webhooks (why PayPal is mentioning IPN)

IPN (Instant Payment Notification) is PayPal’s older server-to-server notification method. It posts transaction updates to a “Notification URL” you configure.

Webhooks are the modern alternative used across PayPal REST integrations: PayPal sends HTTPS POST callbacks to an endpoint on your server when events happen (order approved, capture completed, refund, etc.).

In other words:

• PayPal Standard integrations commonly reference IPN

• PayPal REST integrations should rely on Webhooks (per app / integration)

Why the customer sees an IPN URL for “PayPal Standard” when they’re using PayPal REST

This usually happens for one of these reasons:

1) Their PayPal account still has an IPN Notification URL set (legacy setting)

If their PayPal profile still contains an IPN Notification URL, PayPal may continue attempting to send IPN messages to it (and warn if it fails). PayPal’s own guidance explains IPN is configured in account settings via a “Notification URL”.

2) A third-party integration is overriding IPN settings

PayPal notes that some shopping carts / integrations can send an IPN listener URL as part of their API calls, overriding the account-level IPN setting and triggering failure notifications.

3) The URL shown is for a different plugin (PayPal Standard), not the REST plugin

If the warning references:
/Plugins/PaymentPayPalStandard/IPNHandler
…that is explicitly a PayPal Standard handler path, not REST. This strongly suggests the PayPal account is still configured to send IPNs somewhere (even if the store is now using REST).

What to do (recommended fix)

Step 1 - Confirm which PayPal plugin the storefront is using

• If the storefront is using PayPal REST, you should focus on webhooks

• If they are still using PayPal Standard anywhere, the IPN URL must be correct and reachable

(If they’re only using REST, IPN warnings are usually “legacy noise”, but you still want to remove/disable the failing IPN configuration to stop emails.)

Step 2 - Configure Webhooks correctly for PayPal REST

For PayPal REST, ensure webhooks are created and pointing to the correct, publicly accessible endpoint.

PayPal webhooks:

• are configured per REST app

• send event notifications to your configured webhook listener endpoint

PayPal provides a list of supported webhook event names (useful when choosing what to subscribe to).

Checklist:

• The webhook URL must be publicly accessible over HTTPS

• It must match the correct storefront (include the storefront alias if your platform requires it)

• Confirm events are arriving in PayPal’s Webhooks Events dashboard

Step 3 - Fix or disable the PayPal Standard IPN setting (to stop the warnings)

If the PayPal email is complaining about:
https://www.pigsy.com/Plugins/PaymentPayPalStandard/IPNHandler

…then either:

• that URL is no longer valid/reachable, or

• PayPal shouldn’t be trying to send IPNs to it anymore

PayPal’s IPN setup docs explain that IPN is enabled by specifying the listener URL in the PayPal account profile (and can be changed there).

What the customer should do in their PayPal account:

• Go to the IPN settings (profile / selling tools / Instant Payment Notifications)

• Update the Notification URL to the correct one if they still use PayPal Standard

• Or disable IPN if they no longer use Standard and are fully REST/webhook-based

(Exact UI labels vary by PayPal account type and region, but the concept remains the same: IPN is tied to a Notification URL in account settings.)

How to sanity-check the endpoint

If you want a quick “is the URL alive?” check:

• Try loading the IPNHandler URL in a browser

  • You may get a 404 (expected sometimes), but if the domain doesn’t resolve, SSL fails, or requests are blocked, PayPal will also fail.

• Confirm the URL is publicly accessible (not blocked by firewall / WAF / geo rules)

• Confirm any storefront alias requirement is met (common gotcha when URLs are environment-specific)

FAQ

“But they don’t see any errors in their PayPal dashboard”

That’s possible - PayPal’s warning is often triggered simply because it attempted delivery and didn’t get a successful response. Also, IPN warnings can happen even when IPN is disabled if an integration overrides settings in API calls.

“Do we need IPN for PayPal REST?”

In general: No. PayPal REST integrations should rely on Webhooks for event notifications.

“What should we tell the customer?”

A safe, accurate message is:

• The warning references PayPal IPN, which is a legacy notification mechanism.

• Your PayPal REST integration uses webhooks instead.

• They should ensure webhooks are configured to the correct storefront webhook endpoint.

• They should update/disable the legacy IPN Notification URL that points to /PaymentPayPalStandard/IPNHandler if they’re not using PayPal Standard anymore.

External references (useful links)

• PayPal: What is IPN?

• PayPal Developer: IPN overview & setup

• PayPal Developer: Webhooks overview

• PayPal Developer: Webhook event names

• PayPal: Troubleshooting IPN warnings (including third-party override behaviour)

Applying for an Opayo / SagePay account

To setup a new account please click here and select Infigo Software Limited is selected as your Partner. When filling in an application, you will be asked several questions:

• Are you integrating into an 'off the shelf' shopping basket? Answer: Yes and specify Other
• Which system do you wish to use? Answer: VSP Server
• A list of allowed IP addresses is found at the end of this article.
• The subnet mask for these IP addresses will always be: 255.255.255.000 

Configuring SagePay on your storefront

1. Login to the storefront as an Administrator.

2. Go to Payment Methods and click on Configure alongside Payments.SagePayServerEnterprise 

• Transaction Type:
  • PAYMENT:  to take the payment when a customer enters their credit card
  • DEFERRED:  to capture the funds, but release it later (after shipping items)
  • AUTHENTICATE:  to validate the card but not take any money
• Connect To: this allows you to choose the Test account on Opayo / SagePay before they will move you into Live. Always begin with testing, ensure all transactions go through successfully, and then, when your Live account is enabled by SagePay, enter this menu item and adjust to LIVE
• Vendor Name: this is provided by Opayo / SagePay when you sign up to us the system
• Profile: this dropdown should always be left as LOW

3. Once complete, save and enable to make active.

Whitelisting IP Addresses

This step is required to authorise the transaction, without it the payment will fail. This is configured externally from Infigo, and is instead setup within your Opayo / SagePay administrative tools.

- The IP Addresses you are required to add are: 35.177.47.232 and 3.9.143.80

- As mentioned earlier in this article, the subnet mask should be: 255.255.255.000

Making the PO Number mandatory on checkout ensures you capture the Customer's Purchase Order Number.

1. Go to Admin, Configuration, Payment Methods

2. Locate Purchase Order in the list and click Configure:

3. Enable the 'Purchase Order Number is compulsory' checkbox and click Save:

4. You can enable a PO upload (making it optional or required): 

5. When set to required, you can choose the document type for upload: 

If you would like to change the wording, please refer to Language Strings. 

Go to Admin > Configuration > Payment Plugins > Credit / Debit Card, Payments.Authorize.Net > Configure.

The first section of the plugin configuration is "Authorize.Net Settings"

• Capture mode: When an Authorize.Net payment is cancelled or fails, the order will not be placed until the payment amount is authorized. You can choose one of the following options: 
  • Manually - an admin user will need to click on the "capture" button in Sales > Orders (meaning the admin captures the payment manually). 
  • On order placement/approval - once an order is approved the payment will be taken. 
  • On Shipped - when the order gets shipped, the payment automatically gets captured. Authorized payments can be voided / cancelled.

• API Login ID: this is required and you will get it from your Authorize.Net account (see hint ?)
• Transaction Key: this is required and you will get it from your Authorize.Net account (see hint ?)

• Use sandbox URL: you can test the connection with this setting (see hint ?)
• Submit the payment form automatically: when ticked (enabled) this will automatically load the payment form. When unticked (disabled) the end user will be required to click a "show payment form" at checkout (see hint ?).

The second section is Payment Options.

Please see hints (the question mark alongside each setting) for more information.

• Require Card Code Verification (CCV): This setting is provided by the Address Verification Service (AVS) from banks and card associations to help identify suspicious payment card activity for e-commerce transactions. AVS matches portions of the customer's billing address, as provided by the merchant, against the billing address on file with the issuing bank. Enable this setting if you want to enforce these additional checks
• Enable Credit Card Payments: This allows customers to pay via credit cards
• Show Bank Account Information: Enable this setting if you want to display bank account fields on the payment form.

Security options, show captcha form: enable this if you would like to have your Google security reCAPTCHA enabled in the Authorize.Net iFrame. 

Show Shipping Address Form: Enable this setting if you would like the shipping information entered in Catfish's checkout flow to be displayed in the payment form. 

Billing Address Options, Show Billing Address Form: Enable this setting if you would like the billing information entered in Infigo's checkout flow to be displayed in the payment form.

Customer Options, Show Email Address: Enable this setting if you would like to have the customer's email address on the payment form.

Style Options, Primary Accent Colour: Use this setting to select the primary accent colour of some of the payment form elements. These elements include the buttons, and field line colours. 

Content Editor Tab 

As of April 2025 PCI compliance changes require e-commerce and web applications to increase security at checkout. The payment page where the merchant loads will redirect users to a standardised page which will be locked down to prevent scripts from being injected into the page. The look of the page will be standardised (similarly to that of PayPal and Stripe) like so: 

However, you will be able to edit the header and footer using a rich text editor.

When you go to Admin > Configuration > Payment Plugins > Credit / Debit Card, Payments.Authorize.Net > Configure and click into the Content Editor Tab you will see a number of fields, but only the “Header Content” and “Footer Content” blocks are displayed on the payment page.

To assist with the PCI compliance changes we have left the other fields "Title," "Logo URL," and "Footer Content Extended" in admin so you can move existing content to the new content blocks. They will not be shown on the payment page to the end user. 

1. If you have text in the Title field and/or would like to edit the page header: please move text in the "Title" field to the Header Content field like so: 

2. If you would like add an image (a logo) to the page header: please upload the image/logo using the picture icon like so: 

This will load the below insert image window. Click Insert to upload. 

3. If you have text in the Footer Content Extended field, please move it to the new Footer Content field like so (we have used the example "all major cards accepted" for the purpose of this article. That text will not be in your plugin):  

4. Click Save.

5. To see this on the front end, please impersonate a user and go through the checkout process placing an order.