Portal V2 Online Payment Gateways Implementation

feature

(Jerry P) #1

I’m finishing up writing a gateway class to implement AuthorizeNet and Stripe payment gateways (Square and maybe PayPal in the works) and i’m in the process of integrating into OpenEMR. While use case for portal is clear, implementation in OpenEMR payments, not so much. My thinking is that most practices already have some sort of POS setup for credit card payments so doubtful adding to Payments would be useful. Is this assumption correct?

  • Would a practice ever have a need to run more than one gateway vendor i.e. Authorize and Stripe?
  • Should payment automatically be posted or have billing folks post after being notified of payment?
  • Should allow patient to void payments?(24 hours)
  • Should patient only be allowed to pay against invoice balance and billing determine how applied. eg an itemized invoice is presented with a balance.
  • Only plan to log transaction ids and amounts. Any reason to save card tokens for future payments?
  • Any other popular gateways that would be useful?
  • Any other concerns or work flow suggestions.

@stephenwaite I’ve chosen for new universal gateway class to live with your new library /billing classes. Any problem with this?
Edit: Here is PR for the adventurous among us!


(Stephen Waite) #2

thanks @sjpadgett, yes but if they’re using a virtual terminal than ideally could use payments to charge card and post payment in one swoop but most efficient for a practice will be the portal

  • not likely, it’d be more expensive to have 2 gateway vendors since there are recurring fees even if not running any payments through them
  • prob have a routine for successful payments to be posted by the billing folks like the era maybe?
  • maybe, prob cause more confusion in the end
  • that would be impressive and patient friendly
  • and the auth no.
  • not sure
  • :thinking:
    5.0.2 will be much celebrated :slight_smile:

(Jerry P) #3

@stephenwaite Patient sees and pays


Then patient will see until payment is applied. If this is a gateway payment then invoice is locked. If provider runs credit card then invoice payment is allowed to be modified. Either way once payment is posted then pending is set to complete.

The billing person gets this in Portal Dashboard Audit


Where Biller can post payment and send receipt to patients Secure Mail. I think it is best to post from the audit log instead of leaving and posting elsewhere. But i’m open to all ideas as I don’t have the clinical experience to guide me
.

I will add another notification alert for pending payments in the portal notification widget.

image

Does all this seem reasonable?


(Jerry P) #4

Here is receipt notice to send

And after post in Portal


(Stephen Waite) #5

looks and sounds great, thank you @sjpadgett


(Jerry P) #6

@juggernautsei,
I’m bringing in authorize.net and stripe via a wrapper and universal gateway class so can I go ahead and remove the "stripe/stripe-php" : "6.24.0" package you had brought in for development?


(Dan Ehrlich) #7

What about PayPal? I ask because of how ubiquitous it is.

Stripe is better and more secure though FWIW


(Jerry P) #8

PayPal maybe after code review, testing and in master(prob do Square first). They’re both secured the same way on Portal end as I only use tokenized cards where we never store or pass credit info to the back end. For In House credit cards that provider runs through their POS/Auth service I encrypt all card info.
I posted this tread to get feedback on what folks felt was most needed but as always…crickets 'cept Stephen and now you.
Will bring in a PR later today and will get Brady to do an up for grabs demo so maybe I can get some testers going.
If only I knew of some willing eager folks :slight_smile:


(Jerry P) #9

Okay, PR is up. Not bad for a couple days work but, there’re still features and possibly better user interactions forthcoming after some feedback. Note the invoice in portal that totals columns. I’m thinking of adding that to Front Payment if people find it useful. Probably need to do some reconciliation in the form to make payments and balances make better sense. At least for me :slight_smile:
See PR for how to test and testing credentials. Setup is in Globals->Connectors.
Feel free to keep negative feed back to ones self :slight_smile: I’m kidding of course. Please bring it on and lets have some fun…


(Sherwin Gaddis) #10

@sjpadgett
Yes you can remove that. It has been dormant for years.


(Sherwin Gaddis) #11

Also can recurring billing be setup like for therapy practice so that after a session is posted the self pay can be charged to the card on file.

It would be really nice if there was some documentation or a video presentation on all the features in the patient portal :smiling_face_with_three_hearts:


(Sherwin Gaddis) #12

On this one here. I recently had to change the way payment taken at the front desk were applied to the system. The biller wanted the payments unapplied so that they could correctly apply the payment without having to go in and adjust every payment.

Their issue is with the amount of copay that the front desk was collecting and the amount they would get back from CMS that the patient should pay. Those amount could be different. If they were different and the patient overpaid. CMS would send a refund to the patient.

This was causing mass confusion because patient’s started questioning why they were getting a refund and why was the doctor overcharging them in the first place.

So, I made a change so that the payment was added to the system but left unapplied.


(Jerry P) #13

I thought that the copay was an agreed on amount between service provider and insurance provider depending on plan. So are you saying that CMS has a different copay depending on what is being billed? If not, simple solution is to change the required copay amount in patient insurance setup instead of fudging the amount at post.


(Sherwin Gaddis) #14

@sjpadgett

This is all I know. I just did as I was asked.


(Stephen Waite) #15

there are no copays for medicare part b


(Jerry P) #16

I though so except for a carrier that may bundle into an Advantage plan such as United(AARP) e.t.c. for which they do the billing to Medicare, I believe. Almost always as far as I know, copays are set at contract time for both the service provider and plan holder. Is there such a thing as tiered copay for different services?
In our billing, copays are treated independent of patient payment and not applied to insurance balance and is never reconciled except that the required copay balance is met. Any overage is simply left hanging unless it is noticed by human and the copay overage is distributed elsewhere. Really the overage amount should be automatically applied as a patient payment or refunded by the practice or better yet, be refused at payment time. Copays are simply a non billable fee and should not affect insurance one way or another. Am I over simplifying?
At any rate, Portal Dashboard allows the payment to be posted the same way Front Payment does. Portal does not do any posting which seems right but could befuddle the patient that the payment is carried until providers billing posts.
@juggernautsei, I get your use case can differ because of offshore billing reimbursement practices but I still don’t understand why an insurance provider determines if a patient should get refunds on copays. If there are copays then the correct copay should be corrected in patient insurance settings before creating a claim.


(Stephen Waite) #17

that’s medicare part c, yes copays are tiered esp for specialists, i think i get your drift but copays can be billed out to the person if not collected at time of service and are part of the remittance that is created by the insurance co.


(Stephen Waite) #18

agree with you on overages


(Stephen Waite) #19

but copays would be the same for the provider and not deviate for the services offered by them


(Jerry P) #20

Thanks that helps. So now I can see where it can go wrong on the front end. In the end, that poor billing manager has to be on their toes. I don’t see an immediate solution but I will certainly think it through starting with allowing to split payment across different payment categories and not just invoices ie 30.00 to copay, 20.00 to patient balance or insurance balance. That could go a long way to cut confusion.