Jump to content

design a system to integrate with 3rd parties


Recommended Posts

Hi all,


I'm looking to design a OO system that interacts with 3rd parties who use SOAP, GET AND POST. These 3rd parties each have their own way of more or less doing the same thing.


For example. Say I want to pass them a credit card name, one 3rd party may expect "Mastercard" and another might expect "MSC" to be passed.


At the moment I'm thinking I could, for example have a set method like so:




Another method to find the correct mapping for it:




This may mean a scaleabilty problem if a new card is added in the future.


I could create a method is some subclass that takes these details as params, perhaps something like:


$thirdParty->('$URL_TO_POST_TO', 'SOAP'
"VIS" => "VISA"
// etc


This would make it potentially a nightmare if a lot of params need passed in but would mean if another card was added, the code wouldn't need changed and it would just mean adding another element in the array.


Anyone got any tips or suggestions on how best to tackle this? I'm thinking GET/POST/SOAP parent classes and a "3rd party" subclass. These are just rough ideas.



Thanks in advance,


CaptainChainsaw :)

Link to comment
Share on other sites

Why would you hard code these values rather than putting them into a database which would be infinitely easier to maintain and manage? You can then define the different cards and the "names" that each third party product uses.

Edited by Psycho
Link to comment
Share on other sites

That might be an option but performance is high priority and another db hit might have an effect on that. These card types and other details currently aren't stored on the DB they're simply values on a form, adding the details to a DB and not updating the form dynamically using db values would mean changes in two places.

Link to comment
Share on other sites

You should not be hard-coding data that is variable. If you design your database and logic appropriately the performance should be minimal. You would only need one or two tables. To be truly normalized you would want two tables: one for the card types and an associative table for the vendor names of each card type. But, if performance is a problem and you do not foresee having to add many vendors over time you could have one table with a record for each card type and a column for each vendor. To add a new vendor you would only need to add a column and enter the value that the vendor uses for each card. You would doing a query against a table that only contains a dozen or so records.

Edited by Psycho
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.