Recent Opayo Pi API changes

Created on 23 November 2023, 7 months ago
Updated 11 December 2023, 7 months ago

Problem/Motivation

November 2023 - Opayo have made some changes to their API, in addition to redoing their all their dev API web pages, including the Opayo Pi ones (https://developer.elavon.com/products/opayo/v1/opayo-pi).
The documentation suggest that, when using the 'own form' approach, the tokenisation of the card details should be requested using javascript from the browser.
This module currently requests card detail tokenisation from the back-end: this might continue to work but should, in my opinion, no longer be considered correct practice.

Opayo have also made the customer's phone number a mandatory field for submitting transaction requests.

Steps to reproduce

Proposed resolution

Submit tokenisation from the browser instead of the back-end.
Add means of ensuring customer's phone number is collected in international format.

I've gone down the route of creating my own custom module, currently about 80% complete, which borrows from this module.
If there is interest I am happy to publish it as a module when finished.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

2.0

Component

Miscellaneous

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡΄Norway gisle Norway

    The URL you've linked to does not exist.

  • Country needs to be set on the Elavon developer website (https://developer.elavon.com) to 'United Kingdom' first.
    Then 'API Docs' > 'Partner APIs' > 'Online Payments on Opayo'.

    Opayo 'Form', 'Server', 'Shared' and 'Direct' are under 'Legacy APIs'

  • There is a lot of 'new' stuff in the module I'm working on:
    * Javascript to try to transparently deal with expiration of merchant session keys.
    * Opayo want 'cardholder' field for tokenisation but additionally 'first name' and 'last name' for the strong customer authentication.
    I've ended up adjusting the form fields to present this to the user in a hopefully reasonably intuitive way.
    * Extra step to the checkout flow for 3D Secure authentication with associated custom CheckoutFlow plugin class and resolver
    * New checkout pane to hold the iframe for 3DS
    * Javascript to go along with 3DS.
    * New entity to capture Opayo transaction info
    * Trying to put in a lot of logging

    Wouldn't know where to start if I had to back-port all of that to the existing module.
    Happy to share my source if somebody else wants to tackle that.

  • πŸ‡¬πŸ‡§United Kingdom c_archer Cumbria

    Happy to have a look if you could share you code, how far along have you got?

  • I've got transactions working end-to-end for 'own form' Opayo pi method, including if there's a 3D secure step, on the test environment.
    Lots left to do: refunds, reporting, testing all error cases and general tidying up. I'm guessing another 2-3 weeks.
    Not doing repeat transactions because we don't need them at the moment.
    There's a copy here: https://www.ihbristol.com/sites/default/files/commerce_opayo_pi.zip, but it's very much *not* production ready.

  • πŸ‡¬πŸ‡§United Kingdom c_archer Cumbria

    Thanks had a look over the module and managed to get it working locally. Great work on putting this together, I agree this is different enough a new project would be easier. If you could set this up, I'd be happy to continue testing and work on resolving the remaining bug in the new issue queue.

  • @c_archer
    Sent you a message about the new project (commerce_opayo_pi) β†’

Production build 0.69.0 2024