Control Payment type options in store


Hmm. That might be well out in front of my forked clone. I’ll attempt a merge on a secondary branch and see how that goes. Else, maybe I will need to “cherry pick” those commits onto my repo. Might it make sense to apply those to the repo?


Simple merge from master is recommended and has been practiced by clients. Most changes have been core changes that don’t affect unless you were patching java files. The git-addons script will also simply merge from the addons repo (./git-addons pull paypal).


Ok. So far, it’s been xml and ftl pretty much that I’ve fiddled with. So hopefully, that will go smoothly for me. Should I run the add-on script again after that, or will the merge with master take care of everything?


The addon is a separate call, you can do ./git-addons pull paypal anytime and if there is no changes it will do nothing.

Occasionally there could be a conflict in a *.properties or *.xml file that you have to resolve with git merge but is fairly rare.


Please note: The git-addons script has been updated in the master branch.

It is now possible to use it to easily load the addon’s data, and even pull and load data in one command.

Basically in your case you can load the data on each database (assuming they have already been seeded, and you’re adding the data only for the addon) using:

./git-addons load-demo paypal

You can do pull + load at same time using install-xxxx:

./git-addons install-demo paypal

You can substitute “-demo” with “-extseed” or “-production” (alias) to skip the demo data.

For more info, consult ./git-addons help after you’ve merged, there is also a summary on the Addons page.

(You can also do it using an ant command if needed, which is displayed by the script when you run it, for future reference, but this is a little simpler)


Ok. So I merged your master branch into a new branch from my clone in a local development environment. (Note my original clone was from v.1.14).

Next, I ran the addon pull script. All good… I pushed my new branch. In prod, I fetched it, and checked it out. All ready to run the data seeding…

sudo ./git-addons load-production paypal

Produced this:

SCIPIO-ERP Addons and Themes Git Merging Script

ERROR: Scipio version in framework/base/config/ appears invalid - try updating script?

If I cat/vi that file I have:

# SCIPIO: Release and Version Information
scipio.release.desc=SCIPIO ERP Community Edition

What’s should this file contain instead?


Oh, that would definitely happen. I haven’t followed all the conversations here, so I thought you were using the master branch to begin with.

It’s not common to switch from 1.14 to master (normally you’d re-branching from master and reapply changes), and even though the merge might succeed, you’d be left with small differences like that.

You could try to simply copy over these files from master and replace the ones in your branch with them:


You may have to clone a copy of to get them and copy them over.

This isn’t a normal operation so I’m thinking off the top of my head, but those files should cover it.

The only downside to continuing this way (as opposed to re-branching from master and reapplying your changes) is you get slightly uglier git history.


Ok. I’ll give that shot. It setup my the repo on my dev environment to have multiple remotes. So, I have a branch/connection to pull your updates to that actual master. I can switch to that branch to get straight copies of those files and then drop them over this other branch I’m currently playing with.

I started from 1.14, as I thought was a “stable release”. My plan was to not be merging until later down the road when there was another major upgrade. But, I guess that was the wrong approach. I’m most accustom to the “GitFlow” ( method of branching and merging (or some close analog). With that, updates to “master” are relatively rare, instead frequent changes are applied to a “develop” branch, and in a scenario like this, you’d have a “hot fix” branch you could apply in isolation to whatever branches needed it.

That said, I have confidence I’ll be able to resolve any issues by just checking with you guys. I am blown away by how helpful and responsive you are!


I did not spot earlier that you were using sudo to run:
sudo ./git-addons load-production paypal
Normally we never use sudo for any command in scipio,
./git-addons load-production paypal

This could be causing you issues somewhere, because git will pull files under root user and prevent normal user from modifying them (or depending on umask even from reading them). I am not sure it would have caused an issue here, or that it necessarily will, but it could give you issues at some point.

If you get issues you may need to use 'chown -R …" command to restore permissions on the files.


I have done a very minor tweak to our git-addons script (in our master).

If after you replace the files, somehow you still get a error somewhere, please let me know exactly what OS/environment you are running. (remote chance there is a line ending issue)


I’ll be sure to reset the ownership on the files to the scipio user. My internal documentation includes that actually, but I omitted that detail here. I’ll pull the newest change today.

I believe that line endings are being auto corrected via git, but I’ll watch out for that. I do push/pull this between Windows and Linux, but in Windows I’m using Tortoise git, which has settings to manage that, so Linux endings are applied when I push to a remote.


Close, but no cigar!

I got through the bulk of this, but an error occurs when I test it. The error message is very nebulous! It reads:

An unknown error ocurred while processing PayPal payment, please try again later or contact our support for further information.

After updating the code and pulling it into prod (and restoring the file permissions), I ran ./git-addons load-production paypal successfully. I defined the api credentials for the paypalrest entity per the url provided. They align with the example posted (inclusive of the magic strings), other than they use my sandbox keys of course. I also provided those keys in the xml file for good measure, and I restarted the service. I can go all the way through to the end of process in the store, but then it fails upon submission to PayPal.

I tried to inspect the other side of this, but the PayPal Sandbox API call log page is crashing!! How frustrating!

Here’s a chunk of the log, I’m not sure it reveals anything useful:



I did note that the log shows http rather than https when referring to my url. As discussed in a prior thread, I’m running behind an apache proxy. Scipio thinks it’s on http, but that’s because apache runs it that way with https actually being out in front of it. I don’t know if that’s any help, but I figure I’d better bring it up since it is a deviation from the standard environment.


Is there perhaps a tiny unit test I could execute to confirm I’m able to use my PayPal sandbox in general? Like a few lines of hardcoded javascript, php, python, perl, etc. to just run on the side as a quick sanity check? I could write such, if I had to, but I’d need to spend the time reading up on their api. I figured you know better than I how to test that with minimal effort.


The issue in this case that clientId is not set. On the database side that would be this entry that you have to modify:

<PaymentGatewayPayPalRest paymentGatewayConfigId="PAYPAL_REST_CFG" clientId="AUEJqr6N9UiGntvEJ-Gsn9cw2eTW4MjcUl1KZc3X-jpJAmiKKa342r5z8q9SSpWpmOWYr-a7yB7Uc6y6" secret="EJXE5EC3pbGJvfwWG6fQNobcWXsxpJQ_Zu1EvvdWdZ_E0T9ZgLyxhQOjrGeF0pHO6XGanD9cIp-LhwaY" paymentReturnUrl="returnPaymentPayPalRest" paymentCancelUrl="cancelPaymentPayPalRest" billingAgreementReturnUrl="returnBillingAgreementPayPalRest" billingAgreementCancelUrl="cancelBillingAgreementPayPalRest" />

clientId and secret must match whichever values you set up over at paypal. You basically have to head over here: and set up a live or sandbox (test) account. Then use the values to modify the seed data and reseed. You should also be able to modify those values here: https://localhost:8443/accounting/control/EditPaymentGatewayConfig?paymentGatewayConfigId=PAYPAL_REST_CFG

Also check the values in /addons/paypal/config/ (the paypal.clientId and secret work as fallbacks if the database entry cannot be found).


Make sure you set the appropriate mode as payment.paypal.mode, too (either “sandbox” or “live”)


Thanks, but I’ve done all of that. I think… Does the log indicate otherwise?

When you say I need to “reseed”, should I be running the load data script again? Would it help if I query the database directly to verify the data is there?


Yup, the log indicates that the clientId is null - so not set at all. So we must validate that those values exist in database. I will send you an invite to a private webconference so that we can resolve this quickly.

About http: the log doesn’t show the difference between http and https connections. So nothing to worry about.

<?xml version="1.0" encoding="UTF-8"?><entity-engine-xml>
    <PaymentGatewayPayPalRest billingAgreementCancelUrl="cancelBillingAgreementPayPalRest" billingAgreementReturnUrl="returnBillingAgreementPayPalRest" clientId="[REMOVED]" createdStamp="2018-08-18 00:09:58.0" createdTxStamp="2018-08-18 00:09:58.0" lastUpdatedStamp="2018-08-18 00:09:58.0" lastUpdatedTxStamp="2018-08-18 00:09:58.0" paymentCancelUrl="cancelPaymentPayPalRest" paymentGatewayConfigId="PAYPAL_REST_CFG" paymentReturnUrl="returnPaymentPayPalRest" secret="[REMOVED]"/>


'PAYPAL_REST_CFG', '[REMOVED]', '[REMOVED]', 'returnPaymentPayPalRest', 'cancelPaymentPayPalRest', 'returnBillingAgreementPayPalRest', 'cancelBillingAgreementPayPalRest', '2018-08-18 00:09:58', '2018-08-18 00:09:58', '2018-08-18 00:09:58', '2018-08-18 00:09:58'

The values are present. So that’s weird. (I just replaced those keys with [REMOVED] in my post).


Awesome! I’ll join you in the conference!


Just a note: if you update the paypal addon in near future (./git-addons) please also make sure to merge from scipioce, there was a slight refactor so if you miss the scipioce changes you may get java library error at runtime. thanks