Invocable callout(Post) from processbuilder
From a practical viewpoint, I think the methods that you have right now are splitting the responsibilities of your overall code fairly appropriately. You could further split things up, but the question to ask is what purpose would this serve?

The more methods and classes you break things into, the more you need to jump around in your class(es) to learn (if you're new to the codebase)/remember (if it has been long enough since you last touched the code) how things work.

Instead of focusing on that, there are more pressing issues:


Exceptions as flow control


This is generally viewed as an antipattern (i.e. something to avoid). The main purpose of exceptions is to (more) gracefully handle error conditions where continued processing is impossible. 
In this particular case, running into a System.QueryException should be impossible. In the case where either of your queries returns 0 rows, you can't really continue processing. You'd run into a System.ListException when you try to access  os[0] or prop[0]

Non-bulkified @future call


You're calling your @future method one Id at a time. You can only make 50 @future calls in a given transaction, so if your ProcessBuilder tries to work on 51 records, you're liable to run into this governor limit.
The better option here would be to pass the entire list you accept as an argument to your InvocePostProperty() method to your @future method as well
Building on the previous suggestion, if possible, you should pass more than one event (I'm assuming it's an event service you're using, based on the language) per callout

No notification when async code fails


Asynchronous code, at least for me, has a pretty bad history of not printing debugs to logs. The fact that code is being run async also means that there's no direct way to alert you if the async portion of the code fails.
In my org, using async code means that we need to do our best to catch all possible errors, and create a Case or send an email to an appropriate person to let them know that a failure has occurred



My Suggestions:


I think that Queueable apex is probably more appropriate in your case. Unlike @future methods, queueable apex can be chained ad infinitum
Add explicit error notification to your async method(s)
Attempt to make more than one callout per async transaction. You can have 100 callouts in a single transaction (as long as your callouts in a given transaction don't collectively exceed 120 seconds of execution time)
Make use of the Limits class to determine whether or not you can make another callout in this transaction.
Don't forget to store the records you want to update in a list, and perform DML after you finish all of your callouts for a given transaction
Instead of trying to catch (and swallow) a System.QueryException, add a custom exception inner class to your or_service class. If you detect 0 rows returned by either of your queries, throw a new instance of this exception (and then do explicit notification)