Fat Client Mac O$10 Talk to Browser?

Phil (OmnisList) phil at pgpotter.co.uk
Fri Sep 30 21:39:46 UTC 2022


I just wanted to comment Doug,

Its great being able to share your experience, learn from it, and 
hopefully, if its relevant, protect ourselves in the same situation in 
future.

I was aware you had gone through such issues, and had I found myself 
needing to deal with credit cards directly, for sure I'd get advice from 
you, if I could.

So, thanks Doug.

regards
Phil Potter
Based in Chester in the UK.

On 30/09/2022 21:51, Doug Easterbrook via omnisdev-en wrote:
> hi das.
>
> I hate these conversations.   I hate the hold that the CPI council has over software developers.  PCI is a bitch.  its a lot of work.   The PCI council has rules for determining if things are in scope or out of scope.      Much of it is not for me to decide.
>
> all that I really care about is the general statement  that a lot of people make ‘PCI does not apply to me’.    it is fine to ignore it, but I wouldn’t want people to be ignorant of what the PCI council thinks they want to have a say in.
>
>
> so, lets start with this assertion
>
> Because I only took cards on a 3rd party secure form that I was not responsible for, the questionnaires went real easy.
>
>
> so far, you are right.  I agree.
> 1) PCI questionnaires become real easy.   very easy.   lots of things are ’not applicable’.  a total joy to fill out those forms.
> 2) however, you are still responsible for meeting PCI compliance as a merchant
>
>
> so, this statement is completely wrong.
>
>     "There is no responsibility in that situation.”
>
> The merchant is still responsible for indicating ’not applicable' to a lot of PCI requirements.  It means you have to read them and know that they don’t apply to your situation.
>
>
>
>
> As a merchant
>
> your  responsibility is to ensure ALL the components of the system(s) you are using help you meet PCI compliance.   The choice of how you integrate components goes a long way to mitigating the level of PCI questions you have to deal with.      In many cases, if you have Credit Card volumes under certain levels (globally in the corporations), you can self-assert your compliance and you don’t need auditing.      It is easier, but you still have to think about it.
>
>
>
> as a VAR
>
> if you are a software vendor providing a system that incorporates other companion systems for credit card authorization, the PCI council looks at that as integration.  They still have something to say about it.
>
> example:  we tell our customers to get P2PE devices (ie.e end to end encrypted pin pads that they use for CC auth).    No physical connection to our app, or the workstation.
>
> it means that the app is out of scope,
> it means the workstation is out of scope
> it means that the P2PE device is IN SCOPE - and it is supplied by the bank, who have certified the device.
>
> sound good so far.   we haven’t touched a card, nor have we stored it.
>
>
> since we are commending an entire system for commerce that includes the P2PE device, we have a responsibility (in the PCI council’s eyes) to ensure that the merchant sets up things correctly.  examples are:
> - do not put the P2PE device on the same VLAN as the workstation with our app
> - use firewalls to separate the Vlans
> - use TLS 1.2 in our communications
> - tell the customer not to type the card ,expiry, CVV2, etc into a text field in our app in case they need to authorize later.
>
>
> The PCI council have generally abrogated the responsibilities of the banks to tell people to do the right thing (since the banks are their customers and pay them vast sums, imagine that).   The PCI council moved the responsibility to VARs since they could exert more control over those who supply solutions.
>
>
> think I like it.  no.  its been part of my life for 20 years.    we are aske explicitly if the solution we supply is PCI compliant.
>
>       
>
>
> so, I just don’t want people to think that PCI is' the other guys responsibility' when they suggest a collection of software  that form an overall  system to people.
>
>
> further, if you use a virtual terminal sort of solution, you are effectively requiring customers to confirm to B-IP level of PCI.
>
> B-IP means:
>
> - your system does not have any credit cards in it, nor store it. not have anything to do with them directly.
> - you are using a ’standalone’ PTS approved payment terminal with an ip connection to a payment processor that also has no electronic card holder storage
>
> woe betide if you put that virtual terminal on the same machine as your app.     then you have to consider things like anti virus software, prevention of key loggers and such things in your recommendations how to install your software in a safe manner in companionship with the other software (which could be fully PCI compliant).
>
>
>
> so.  do what you want.   do it how you want.   pretend its not you.     just know, that you can’t relegate yourself or your system into a bit player.    if somebody gets sued by the PCI council and you didn’t take reasonable steps and advise a customer how to to be safe;  as an IT person, you’d be deemed as ’should have reasonably known’.   That brings the notion of being responsible right back to square one.
>
>
> it is easy to pretend it is the other guy and not your fault for doing nothing.
>
>
>
> just my opinion.
>
>
> and now, I’ll say no more.
>
>
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
>
>> On Sep 30, 2022, at 9:18 AM, Das Goravani<goravanis at gmail.com>  wrote:
>>
>>
>> Doug,
>>
>> YES everyone has to deal with it. Or merchants do anyways. BUT, when doing those quarterly or whatever PCI compliance questionnaires, IF you do not store credit card details, you BYPASS MOST of the questionnaire and it’s a no brainer, it’s easy, etc.
>>
>> And the VAR does not need to have his software reviewed and certified or whatever that is..
>>
>> If the fields, forms, etc., are all hosted by a third party, you have very low PCI responsibility.
>>
>> I know, because I was a credit card merchant the full old fashioned way for a very long time during PCI times.
>>
>> Because I only took cards on a 3rd party secure form that I was not responsible for, the questionnaires went real easy. There is no responsibility in that situation.
>>
>> This is what I’ve gleaned so far anyways.
>>
>> Das
>>
>> Ps: Tell me if you think I’m wrong.
>>
>>
>>
>>> On Sep 30, 2022, at 11:24 AM, Doug Easterbrook via omnisdev-en<omnisdev-en at lists.omnis-dev.com>  wrote:
>>>
>>> hi das
>>>
>>> scott offered to help you with emerge pay
>>>
>>>
>>> I hate to tell you —   If a customer takes credit cards for any reason (wether on computer, manually, pin pad, the old fashioned way of putting the card into an imprinter and taking a physical record of the card)…
>>>
>>> they are subject to PCI.    They can choose to follow them or not, get audited or not.    but the credit card companies (PCI) required all merchants  to be responsible for the PCI rules.    truly, nothing every happens to people who don’t follow PCI rules — unless there is a credit card breach.      and then if the PCI council finds out that there is no attempt to be secure with credit cards and implement the rules, they’ll fin the merchant.  and can be lots of money for each lost card.
>>>
>>>
>>> one of our smaller customers ended up getting a 10,000 USD fine about 15 years ago ….   because they exposed cards in a way that they shouldnt
>>>
>>> just saying.    you can ignore and see what happens.    ignorance may cause a merchant to lose the ability to take credit cards.
>>>
>>>
>>> PCI is isn’t just about cards and computers.    it is about how card data is handled in a business, whether computerized or not.
>>>
>>>
>>> sigh.   I hate having to say the above.
>>>
>>>
>>>
>>> Doug Easterbrook
>>> Arts Management Systems Ltd.
>>> mailto:doug at artsman.com  <mailto:doug at artsman.com>
>>> http://www.artsman.com  <http://www.artsman.com/>
>>> Phone (403) 650-1978
>>>
>>>> On Sep 30, 2022, at 8:04 AM, Das Goravani <goravanis at gmail.com  <mailto:goravanis at gmail.com>> wrote:
>>>>
>>>>
>>>> Dear Listers,
>>>>
>>>> Greetings.
>>>>
>>>> On behalf of a Small Omnis based VAR with many clients.
>>>>
>>>> Studio 8 or 10.22, Cross Platform but esp. Mac, Fat Client
>>>>
>>>> We are willing to pay for your direction.
>>>>
>>>> Or maybe some one of you might already know how to do this and can say so easily.
>>>>
>>>> Herein we are not asking you to spend lots of time and do the work of the coding, rather we are seeking DIRECTION, HOW TO make this work.
>>>>
>>>> Situation: This VAR MUST use "EmergePay" as their credit card processor for reasons that are absolute and do not bend.
>>>>
>>>> https://dev.gravitypayments.com/docs/emergepay/  <https://dev.gravitypayments.com/docs/emergepay/>  <https://dev.gravitypayments.com/docs/emergepay/  <https://dev.gravitypayments.com/docs/emergepay/>>
>>>>
>>>> This processor offers an HTTP REST JSON interface API Reference.. but this they say leaves you open to PCI so this is OUT.
>>>>
>>>> We want to NOT have to deal with PCI.
>>>>
>>>> EmergePay says you then have to use one of their FOUR other methods of connecting with them. See the four methods on the web page of the above link.
>>>>
>>>> These four other methods are all web based. VAR is fat client.
>>>>
>>>> The question I have is: Is there a way to implement a web based thing somehow connected to the fat client?
>>>>
>>>> How to pass in data and capture their success or failure message in the fat client?
>>>>
>>>> This project MUST get done SOMEHOW. Failure is not an option.
>>>>
>>>> I am wondering if the solution might be to use the Javascript Remote Form, since that has Javascript objects, a lot of the four solutions EmergePay offers use Javascript a lot. There is a way to use a Remote Form with the fat client, and tie it to the fat client so that the two can talk. I have seen this as a tech note on the Omnis site. Maybe that is how the solution will unfold.
>>>>
>>>> Would you please, if you know how to do this, look over the four methods they offer on above link. Determine which ones of the four could work with Fat Client somehow. Inform us which, and tell us how to do it, basic directions, as I have a hard time understanding their docs.
>>>>
>>>> One reality to mention is that the Var has an acceptable solution already in place on Windows. The pressing problem is the Mac.
>>>>
>>>> There is one of you out there who would read their stuff and come up with a solution for us. Problem is to get you to look into this from your otherwise already busy schedule.
>>>>
>>>> Hence it’s a paying gig. You don’t need to donate your time.
>>>>
>>>> Thank you for your input.
>>>>
>>>> Das Goravani
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _____________________________________________________________
>>>> Manage your list subscriptions athttps://lists.omnis-dev.com  <https://lists.omnis-dev.com/>
>>>> Start a new message ->mailto:omnisdev-en at lists.omnis-dev.com  <mailto:omnisdev-en at lists.omnis-dev.com>  
>>> _____________________________________________________________
>>> Manage your list subscriptions athttps://lists.omnis-dev.com  <https://lists.omnis-dev.com/>
>>> Start a new message ->mailto:omnisdev-en at lists.omnis-dev.com  <mailto:omnisdev-en at lists.omnis-dev.com>
>> _____________________________________________________________
>> Manage your list subscriptions athttps://lists.omnis-dev.com
>> Start a new message ->mailto:omnisdev-en at lists.omnis-dev.com  
> _____________________________________________________________
> Manage your list subscriptions athttps://lists.omnis-dev.com
> Start a new message ->mailto:omnisdev-en at lists.omnis-dev.com  


More information about the omnisdev-en mailing list