Configuring PaymentIQ (Devcode) with your QashPay account: config & field mapping

This guide explains how to map your QashPay (ACI Open Payment Platform) channel credentials into a PaymentIQ PayonConfig integration. It is written for merchants and integrators who route card payments through PaymentIQ / Devcode and process them on the QashPay platform.

By the end you will know where to find each credential in the back office, what every field in PayonConfig means, and how the 3-D Secure and non-3DS channels fit together.

Finding the integration in PaymentIQ (important naming note)

In PaymentIQ / Devcode, the QashPay integration is listed under our previous brand name, “Quaife” (quaife.net). If you go looking for “QashPay” in the PaymentIQ provider catalog you will not find it — open the Quaife provider integration instead. It is the same service.

You will also see a third name in your configuration and logs: Payon. This is the underlying PaymentIQ integration module for the platform (for example the configuration class com.devcode.paymentiq.integration.payon.PayonConfig, the PSP Payon, and bean commands such as payonCreditcardDepositCmd). To summarise the names you will encounter:

All three refer to the same integration. The rest of this guide uses “QashPay” for the platform and PayonConfig for the configuration object.

Before you begin

You will need:

• An active QashPay merchant account with at least one provisioned channel.
• Access to the QashPay back office, where channel credentials are displayed.
• A PaymentIQ / Devcode environment where you can edit the com.devcode.paymentiq.integration.payon.PayonConfig configuration. In the PaymentIQ provider catalog, select the Quaife integration (our previous brand) — see the naming note above.

If a channel has not been provisioned yet, or you are missing back-office access, contact your QashPay integration manager before continuing.

Step 1 — Locate your channel credentials

In the back office, open the channel you want to configure. Each channel detail page shows the following values:

Important: the SENDER and the User ID are different values and are easy to confuse — they often share the same prefix and differ only in the last few characters. Map them carefully as described below.

Step 2 — Understand the config structure

A typical PayonConfig contains a global on/off switch and one or more <accounts>, each holding an <account> credential block keyed by an account name:

<com.devcode.paymentiq.integration.payon.PayonConfig>
    <enabled>true</enabled>
    <useViqProxy>true</useViqProxy>
    <accounts>
        <entry>
            <string>ACAPTURE_N3DS</string>
            <account> ... </account>
        </entry>
        <entry>
            <string>ACAPTURE_3DS</string>
            <account> ... </account>
        </entry>
    </accounts>
</com.devcode.paymentiq.integration.payon.PayonConfig>

The two entries above correspond to two separate QashPay channels: one without 3-D Secure (ACAPTURE_N3DS) and one with 3-D Secure enabled (ACAPTURE_3DS). Each entry takes the credentials of its own channel. A single channel cannot serve both roles.

Step 3 — Field-by-field mapping

Within each <account> block, map the fields as follows:

Example of a completed non-3DS account block (placeholder values shown):

<account>
    <username>YOUR_USER_ID</username>
    <password>YOUR_PASSWORD</password>
    <serviceEndpoint>https://test.oppwa.com/v1</serviceEndpoint>
    <merchantId>YOUR_SENDER_ENTITY_ID</merchantId>
    <redirectUrl>${baseRedirectUrl}/api/payon/deposit/redirect/form/${ptx.txRefId}</redirectUrl>
    <use3DSecure>false</use3DSecure>
    <useTokenId>false</useTokenId>
    <version>form</version>
    <accessToken>YOUR_ACCESS_TOKEN</accessToken>
</account>

Access token

The access token is a base64-encoded value. When decoded, it has the form:

<User ID>|<Password>

This is useful for two reasons. First, it lets you confirm you have copied the correct User ID. Second, if a password appears to contain unusual characters, decoding the token confirms the exact characters to use — the password is whatever follows the |, character for character.

Treat the access token with the same care as the password: anyone holding it holds your credentials.

3-D Secure and non-3DS channels

PaymentIQ routes transactions to the appropriate account based on whether 3-D Secure should apply. To support both flows you need two channels:

• Non-3DS channel → maps to the ACAPTURE_N3DS entry, with use3DSecure set to false.
• 3DS channel → maps to the ACAPTURE_3DS entry, with use3DSecure set to true.

Open each channel separately in the back office and copy its own SENDER, User ID, password, and access token into the matching entry. A common setup error is swapping the two channels — always verify that the channel’s 3DS configuration matches the use3DSecure value in the entry it is placed in.

Visa AFT (Account Funding) fields

If your account processes Visa Account Funding Transactions, the account block includes additional merchant descriptor fields. These are not secret — they are your registered merchant details — but they must match the data the platform holds for the entity, so source them from your QashPay configuration rather than entering them from memory.

Endpoints and environments

QashPay runs separate test and production environments, and credentials are issued per environment.

• Test: https://test.oppwa.com/v1 — use with test channel credentials for integration work.
• Live: https://oppwa.com/v1 — use only with production credentials.

If your back-office portal links use a regional cluster (for example a host beginning with eu-test.), and you encounter authentication or entity-not-found errors against the generic host, try the matching regional API host (for example https://eu-test.oppwa.com/v1). The credentials must be used against the same cluster on which they were issued.

When moving from test to live, change both the serviceEndpoint host and all four secret values (SENDER/entity ID, User ID, password, access token). Test credentials do not work in production and vice versa.

Security best practices

• Do not commit the password or accessToken to source control in plain text. Inject them from environment variables or a secrets manager.
• Keep production credentials out of shared documents, screenshots, and tickets.
• Rotate credentials if you suspect they have been exposed, and request new ones through your integration manager.
• Restrict back-office access to the people who need it.

Troubleshooting

Going live checklist

• Switch serviceEndpoint to the production host.
• Replace SENDER, User ID, password, and access token with production values for each channel.
• Confirm use3DSecure is correct for each entry.
• Confirm AFT/descriptor fields (if used) match production records.
• Run a small live test transaction before enabling full traffic.

If anything in your configuration does not behave as expected after following this guide, contact your QashPay integration manager with your channel name and the error response you received.